Why Language-Oriented Programming? Why Racket?

Why Language-Oriented Programming? Why Racket?
beautifulracket.com

But.

(You knew there was a "but").

While I don't quite agree with the assertion that with the right tooling (so: this tooling), creating a language is as easy as creating a library, I don't think it would solve our problems even if it were true.

Language design is much harder than library design, even if the tooling is perfect and transparent. In the extreme we're going to end up with what Alan Kay calls inverse vandalism[2] aka the Mount Everest Effect: making things because we can, not because we should or they're good.

In essence, designing a (domain specific) language should be your last resort, not your first resort. At least one that requires a parser or macro system to implement. After all, when we create a library, we are in fact creating a domain specific language, or at least a domain specific vocabulary. A framework goes a little further towards the idea of language. In fact, the first version of Simula was a simulation DSL. It was the second version that made the language into an OO language and the simulation "DSL" into a framework. The advantage being that you can use the same language with different frameworks for other domains.

If we look at natural language, it is very much the same: we use the same language to talk about any number of domains, the most we tend to add is some domain-specific vocabulary. Imagine the tower of babel we would suffer under if every domain had a completely new and different language!

That effect was very much encountered and later described by the LRG at PARC when they started using Smalltalk 72, which allowed every object to defined its own language[3]. It was chaos! Turns out we are not very good language designers in the heat of the programming battle. So they very consciously made the language more restrictive later. However, the Smalltalk message syntax is specifically designed to give you something akin to DSL, but without most of the problems[4].

A similar effect was documented by Bonnie Nardi for end users. Here as well, the expectation was that users would prefer domain-specific tools that were tailored exactly to their needs. This, surprisingly, turned out not to be the case. End users apparently vastly prefer general tools, even if the effort to adapt them to specific tasks is greater (see also: people writing documents in Excel...)

That said, current general purpose programming languages are probably not quite flexible enough. I think there is a sweet spot to be found somewhere between Smalltalk-80 and something like Racket.

[1] https://racketfest.com

[2] http://worrydream.com/EarlyHistoryOfSmalltalk/

[3] http://stephane.ducasse.free.fr/FreeBooks/BitsOfHistory/Bits...

[4] https://youtu.be/Ao9W93OxQ7U?t=627

Neither the sntax object, nor hygiene are of concern when you build external DSLs, which the author's examples seem to be.

I have not yet seen a compelling argument for Racket there vs. for instance a parser generator framework.

I might just be missing the point. Either way the author's convincing seemed to have failed for me.