-
Notifications
You must be signed in to change notification settings - Fork 1
Background
Years ago, I began making a language called lin. lin initially began as a weekend mini-experiment in designing a language that:
- was easy to program in.
- was easy to make.
- incorporated design patterns from both practical and esoteric languages that I liked.
After years of hiatus, I revisited lin with a fresh mindset, fleshing it out further. But this draft implementation became rather cumbersome, and I found that the growing codebase as well as JavaScript as a language were bogging me down. Thus, I decided to wipe the slate and reimplement lin in 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. But soon, I found that the .NET ecosystem as a whole was rather... unapproachable? Foreign? In any case, I switched to Scala, which provided the same functional benefits but with a subjectively more amenable ecosystem for development.
Most programming languages have what I call - for lack of a better term - "syntax noise." ("Boilerplate" seems to be a reasonably synonymous term?) As a demonstration, here's a JavaScript snippet:
[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 listed are nice
indicators for both your eyes and the parser. Personally though, I 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 (this is subjective). But of course, there are languages that can do this same task with even less noise. 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 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. Some of these ideas include:
- APL/J/K vectorization
- How BQN works with nested structures
- JavaScript type coercion/"type fluidity"
- A lot of concepts associated with functional programming languages in general
The challenge with sclin is to merge these potentially disparate features into a simple yet flexible design that can maintain expressiveness over a variety of programming paradigms. Performance is not a priority at this stage; as sclin matures over time, this priority may change.
Made with ❤️ by Ben Pang (@molarmanful).