Background

Years ago, I began making a language called lin. Initially a weekend mini-experiment in designing a language that:

• was easy to program in.
• was easy to implement.
• incorporated design patterns from both practical and esoteric languages that I liked.

After a few years of hiatus, I revisited lin with a fresh mindset, fleshing it out significantly. However, this draft implementation became rather cumbersome, and I found that I was being bogged down by the growing codebase as well as Node.js as a language. Thus, I decided to wipe the slate and reimplement lin using a new language.

At first, I began the reimplementation using F# - flin. Creating interpreters using functional languages can be wonderfully convenient; I was able to let F# handle the lower-level mechanics like GC while I focused on reasoning out the higher-level abstractions. However, I found that the .NET ecosystem as a whole was relatively... unapproachable? Foreign? In any case, I switched to Scala, which provided the same functional benefits but with a subjectively more amenable ecosystem for development.

Motivations

Most programming languages have what I call - for lack of a better term - "syntax noise." Here's a Javascript snippet to demonstrate what I mean:

[1, 2, 3, 4].map(function(x){
  return x + 1;
});

, ., (), {}, function, return, and ; are all syntax noise. Not all syntax noise is "bad" - after all, most of these noises I just listed are nice indicators for your eyes to read. However, I personally find that I prefer this much more:

[1, 2, 3, 4].map(x => x + 1)

It's more concise, it's more pleasant to write, and it's way cooler to look at (in my opinion). But of course, there are languages that can do this same task even less noisily. Take, for example, Haskell:

map (+1) [1, 2, 3, 4]

Or K:

1+1 2 3 4

K's vectorization removes the need for a map function in this case, creating a piece of code that is elegantly compact and straightforward.

I tend to think of sclin as a "fantasy-lang" that incorporates design features I like/want but may not necessarily be practical in a production environment. A few of these ideas include:

• APL/J/K vectorization
• How BQN works with nested structures
• Javascript type coercion
• A lot of concepts associated with functional programming languages in general

The challenge with sclin is to merge all of these potentially disparate features into a simple yet flexible design that can retain maximum expressiveness over a variety of programming paradigms. Performance is currently not a priority; however, as sclin matures over time, this priority may change.