(2023-05-25) Domain-specific languages as a mindset
---------------------------------------------------
Little has happened during these 4 days, but I had implemented a TinyChoice
interactive fiction interpreter in POSIX AWK (available in the Downloads 
section) and fixed collisions in my BroPix engine (probably will rewrite 
AWPix accordingly when I have time too). Anyway, I want to continue my 
research in the area of this kind of "no-coding development". Because, if we 
really think of it, both TinyChoice and even Pix64 are perfect examples of 
an entire artificial language class called domain-specific languages, or 
DSLs. And it doesn't matter in this case whether or not these languages are 
text-based or graphical (e.g. OpenSCAD is text-based but describes 3D 
objects, and Pure Data is graphical but describes sound generation). What 
matters is that they reduce the _conceptual_ complexity of creating new 
things in the particular domain they aim for.

But... How do we distinguish between DSLs and just well-implemented
"traditional" programming language libraries that just offer the right level 
of abstraction? Well, to me personally, a DSL is something that doesn't 
require the knowledge of _any_ aspect of the language it's written _in_ to 
create things with this DSL. Like, you don't need to know C to write SQL 
queries to the DBMS written in C, you don't need to know JS or C# to draw 
Pix64 games that would run in the official Pix64 environment or my BroPix, 
you don't need to know JS or AWK to write TinyChoice story games, and so on. 
But, when someone says that Lisp/Scheme/Racket/Rebol/Red/Haskell/ML/Nemerle 
are perfect for creating DSLs because of their homoiconicity and/or macro 
system, it doesn't make any sense. When you "create a DSL" in them, you 
don't write in your DSL afterwards, you still write in 
Lisp/Scheme/Racket/Rebol/Red/Haskell/ML/Nemerle, obeying the same syntax 
rules and everything¸ just on a much higher level of abstraction. Same with 
Forth - you can abstract everything away with clever word definitions, but 
it still remains Forth with its own rules, like significant whitespace and 
having to put the operands before the words, that is, unless you implement 
all sorts of crazy tricks just to make syntax nicer-looking for 
non-programmers. For me, this is not what a true DSL looks like. A true DSL 
is _fully_ implementation-agnostic and generally cannot just be rephrased as 
a series of high-level library calls in the underlying language, otherwise 
the entire purpose of creating it is defeated as it wouldn't reduce the 
conceptual complexity, only the amount of code you have to type/draw to get 
things done.

Take, for example, the two most popular DSLs out there, HTML and SQL. And
then think how much computational work is actually done under the hood to 
display a complex page correctly (even a static and unstyled one) or to 
execute your DB query in an optimal way. You cannot, in general, rewrite 
this as a series of function calls. And even in a miniscule amount of 
particular cases where you can, you'll have to fully rewrite your program on 
every significant structural change in your document or query. And again, 
you don't care which language or platform is underneath, you don't have to 
be a programmer to use HTML or SQL to do what needs to be done. This is the 
power of DSLs.

Now, why would I write about all these (mostly) obvious things here? Because,
well, people still think of "I'm not a programmer" as a universal excuse for 
not getting familiar with creativity tools, and programmers, in turn, cannot 
think out of the box to radically reduce the complexity of their tools for 
everyone else. Even at the expense of their universality. No one suffers due 
to HTML or SQL not being Turing-complete. Because no one needs them to be 
Turing-complete in the first place to do their job. To understand this, you 
need to switch your brain to the "task-first" mindset. Of course, even in 
this case your choice must pass some sanity checks (e.g. whatever the 
problem is, Faildows is not a solution but a source of more problems) but 
you should not focus on the tooling too much. On the other hand, if your 
tasks are relatively complex and you can't find a ready-made tool to solve 
them, perhaps THIS is the chance to put some one-time effort into creating 
your own DSL in whatever shape you see fit. This way, you only spend time 
once to deal with that complexity and then it pays you back many more times. 
And if your DSL is high-level enough (as it generally should be), it would 
allow to involve non-programmers in solving your (or their) problems in the 
same domain too.

Domain-specific languages allow us to tell computers what we need them to do
with little to no low-level details getting in the way. The less low-level 
details we need to specify, the better. And the biggest paradox of all this 
is that, despite not always being Turing-complete and always being built on 
top of "traditional" runtimes, DSLs are much closer to the initial, possibly 
never fully reachable, idea of computer programming itself.

--- Luxferre ---