In previous posts, I’ve speculated that one of the necessary ingredients for the ascent of a new “champion” programming language is that the overall computing market should expand significantly.
This seems to have been the case in the past, but will the pattern necessarily repeat itself? One could plausibly argue that as computing becomes ever more pervasive, it also becomes ever more diverse and that “one size fits all” programming languages will be displaced by languages specifically tailored to the needs of particular domains.
The argument has merit and does not lack proponents. After all, most communities of experts quickly develop domain specific jargons that help them communicate concisely and precisely with each other, even if this comes at the expense of the ability to communicate with outsiders.
Apart from the LISP faithful, who inevitably can (and do) point out that every programming language idea worthy of consideration has been present in LISP since shortly after I was born, the most vocal proponents of Domain Specific Languages tend to be from the Modeling community. A typical pitch goes something like this: “I have (or am building) a system that allows you to construct graphical models from an open ended set of shapes and lines. To create a domain specific language, you merely choose a vocabulary of shapes and line and add some syntactic and semantic constraints on how these shapes and lines combine. Then you attach a particular semantics to the language, typically by combining together elements from some convenient collection of semantic constructs that come with the system. Now you have a DSL from which my system is (or will be) able to automatically generate executable code, prove correctness properties, and so on.” For those of us who are “graphically challenged”, there is usually the option to create traditional concrete syntaxes as well.
Intriguing as these systems/proposals are, some words of caution are in order. As the Lispers point out there is not really anything new here. If we look at the domain specific jargons developed by communities of experts, we hardly ever see major departures in alphabet, pronunciation and grammar. For the most part, domain specific jargons are constructed by adding new words to English, sometimes accompanied by new symbols to help with conciseness.
It also bears noting that jargons are seldom designed as a conscious act. Instead, they slowly evolve along with the supporting community, typically in the context of an education system that teaches the jargon along with the expertise.
To me, this seems more like the gradual evolution of routine libraries and frameworks tailored to specific communities, than it seems to me a like new Tower of Babel.
To conclude: programming language design is really hard. A set of innovations that address our major pain points in a coherent way is more likely to come our way in the form a general purpose language created by an inspired team of language experts. Domain specific jargons will not go away, but they will always be based on top of general purpose languages rather than collectively displacing them.