> ...writing DSLs ... or make the language itself better
Emphatically: YES.
:-)
To clarify, hopefully, just a little bit: the DSL approach certainly appears the most promising so far. But there are a few issues. One is that language creation, maintenance, interoperability and comprehension become critical issues very quickly, even with amazing tools. (One could argue that amazing tools make the problem worse, because they hasten proliferation).
Then you notice that even some apparently pretty radical DSLs actually have quite a bit in common. And the things that separate them are just variants of a few simple architectural elements (dataflow, constraints, storage, data-definition).
You also remember from Guy Steele[1] that languages should not be "a thing", but rather a "pattern for growth", and from natural languages that we don't really invent entire new languages for specific domains, at most we add some vocabulary/jargon. So DSLs should not be a thing, what should be a thing is a language that allows us to build APIs that have the benefits we want from DSLs. And so while Lisp Macros certainly point the way, I don't think they're the answer. Smalltalk's keyword syntax is closer, despite or maybe because it is less powerful[2], and Grace's extension of keyword syntax gets us even closer.
So we need a language that allows us to build what we would consider DSLs as APIs. For that, it will also need to abandon call/return as the dominant/only generalized abstraction mechanism[3]
I'm really interested in seeing the evolution of Kotlin with regard to its use in building DSLs.
I saw a talk by Christina Lee and Huyen Tue Dao that builds one on the type system (lambda extension fimctions) that feels very intuitive.
https://www.youtube.com/watch?v=OmwjrVawHqA
Emphatically: YES.
:-)
To clarify, hopefully, just a little bit: the DSL approach certainly appears the most promising so far. But there are a few issues. One is that language creation, maintenance, interoperability and comprehension become critical issues very quickly, even with amazing tools. (One could argue that amazing tools make the problem worse, because they hasten proliferation).
Then you notice that even some apparently pretty radical DSLs actually have quite a bit in common. And the things that separate them are just variants of a few simple architectural elements (dataflow, constraints, storage, data-definition).
You also remember from Guy Steele[1] that languages should not be "a thing", but rather a "pattern for growth", and from natural languages that we don't really invent entire new languages for specific domains, at most we add some vocabulary/jargon. So DSLs should not be a thing, what should be a thing is a language that allows us to build APIs that have the benefits we want from DSLs. And so while Lisp Macros certainly point the way, I don't think they're the answer. Smalltalk's keyword syntax is closer, despite or maybe because it is less powerful[2], and Grace's extension of keyword syntax gets us even closer.
So we need a language that allows us to build what we would consider DSLs as APIs. For that, it will also need to abandon call/return as the dominant/only generalized abstraction mechanism[3]
[1] https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
[2] https://youtu.be/P2mh92d-T3Y?t=564
[3] http://objective.st/