Programming a Problem-Oriented Language (1970)

Speaking from the armchair, I'm gonna go with "not really". Part of what makes a good DSL good is that both its semantics and its syntax is well-adapted to the problem domain. And they don't necessarily have to be built up within the syntax of some other language. Gherkin comes to mind as an example, or perhaps Inform.

Whereas what Moore's talking about (I think - I haven't read all of the linked article just now, of course, but once upon a time I did belong to the Chuck Moore fan club.) is something closer to just writing well-factored code - you build up a bunch of small routines to do small problems, and build other routines on top of those, until you've constructed a library that lets you speak about the problem succinctly. This isn't really too far off from what Abelman and Sussman were advocating in SICP. (And personally I like to think of Forth and Scheme as being two different sides of the same coin.)

They're both useful concepts, but they're useful for different things. DSLs are great for many tasks, but building a good DSL takes a lot of time, so it isn't really worthwhile unless you expect it to be used a lot. OTOH, this "problem-oriented" concept is useful most everywhere, including for writing one-offs. I'm less certain of the value of using something like Forth's compiling words or Scheme's macros to do it, though - metaprogramming makes me feel like a superhero, but it also makes me want to kick myself when I need to try and make sense of something I wrote two years previously.

Moore seems to have a very different conceptualization of what good software is compared to the common wisdom.

You have to remember why globals are considered "evil" today: 1) bad for modularity 2) bad if you have threads 3) bad for debugging (referential transparency etc.)

In the seventies, I think that threads simply didn't exist. As for modularity, it is pretty clear from the rest of the book that Moore doesn't consider it as something important. He prefers high performance, ad hoc code. This made sense given the limited power of CPUs at that time, and this still makes sense in the embedded world, sometimes. Finally, the negative impact of global variables is probably proportional to the size of the program. He is talking about programs that could easily fit in the L1 cache of yesterday's Pentiums (a few dozen of kilobytes max).

Furthermore when one programs in Forth, one problem is that you simply can't declare local variables: all you have is two stacks. It often simplifies a lot the functions ("words" in Forth lingo) to "offload" some data into (global) variables. This actually helps with debugging, given that in older systems one had very few debugging tools, because one could interrupt the program and look at the state of those variables in order to guess what's going on.