5 ms·

In my experience, as you learn more about lambda calculus and type theory (LC, STLC, System-F, System-Fw, CiC) the peculiarities of language designs start to fa

In my experience, as you learn more about lambda calculus and type theory (LC, STLC, System-F, System-Fw, CiC) the peculiarities of language designs start to fade. This is because when you see a weird-looking language feature, instead of internalizing it as a unique design with its own unique character, you tend to see it as "syntactic sugar" on elemental theories. That said, some languages are more ergonomic than others, especially when you compare them against particular domains. But IMO that's a problem that transcends language design. All tools, not just a language, should be fit to the domain. And in general you can build APIs and libraries that can reasonably fit any language to a domain. Edit: slight simplification.

mr_luc 5y ago
I'd definitely agree with the specific point of both paragraphs, especially because you said 'language designs' in the first. But I think the essay uses 'language' to mean what you do in your second paragraph, 'features'/stdlib/ecosystem -- the whole experience of working with that material in practice. And in that sense, I think the value of 'weird' languages is that they can package so many different mutually-reenforcing design decisions together that they literally can have the 'think different' effect described in the essay. Taking one example that's kinda-weird, kinda-mainstream -- a 'language' like Erlang includes way more than a Prolog-inspired syntax for a simple functional language, and when you look closely at it, it's not simple to just recreate by pulling in features ad-hoc; the language, its stdlib, and its VM complement each other and have informed each others' design. Probably the feature that most comes to mind when we think of Erlang is that it 'goes all-in' on message passing in a functional language. 'All in' meaning that they've made decisions like: being willing to copy a lot if needed, little details like keeping a count of reductions, big things like pulling in concerns that are often left to the OS when working in other languages like process scheduling, preemption, and supervision, and providing a toolkit out of the box that supports building full systems via Nodes with Applications with trees of Supervisors of Processes (all of which are effectively language concepts now), etc. Well, every one of those decisions is eyebrow-raising to somebody or a lot of somebodies. But if you do go all-in on that combo of capabilities, what's it like? A good engineering team with a lot of money can fit another language and another VM to the same kinds of domains that Erlang is a fit for. (Not that you can get people to agree what those domains are, even within Ericcson apparently). But their solution will necessarily look very different, and the difference between what's easy/hard in their approach vs. an erlang-ish approach is what the weird language can teach us.

mr_luc 5y ago

I'd definitely agree with the specific point of both paragraphs, especially because you said 'language designs' in the first. But I think the essay uses 'language' to mean what you do in your second paragraph, 'features'/stdlib/ecosystem -- the whole experience of working with that material in practice. And in that sense, I think the value of 'weird' languages is that they can package so many different mutually-reenforcing design decisions together that they literally can have the 'think different' effect described in the essay. Taking one example that's kinda-weird, kinda-mainstream -- a 'language' like Erlang includes way more than a Prolog-inspired syntax for a simple functional language, and when you look closely at it, it's not simple to just recreate by pulling in features ad-hoc; the language, its stdlib, and its VM complement each other and have informed each others' design. Probably the feature that most comes to mind when we think of Erlang is that it 'goes all-in' on message passing in a functional language. 'All in' meaning that they've made decisions like: being willing to copy a lot if needed, little details like keeping a count of reductions, big things like pulling in concerns that are often left to the OS when working in other languages like process scheduling, preemption, and supervision, and providing a toolkit out of the box that supports building full systems via Nodes with Applications with trees of Supervisors of Processes (all of which are effectively language concepts now), etc. Well, every one of those decisions is eyebrow-raising to somebody or a lot of somebodies. But if you do go all-in on that combo of capabilities, what's it like? A good engineering team with a lot of money can fit another language and another VM to the same kinds of domains that Erlang is a fit for. (Not that you can get people to agree what those domains are, even within Ericcson apparently). But their solution will necessarily look very different, and the difference between what's easy/hard in their approach vs. an erlang-ish approach is what the weird language can teach us.