You cannot implement simple, modular, debuggable, composable DSLs with functions alone. And you cannot tackle complexity without DSLs.
> Yes, macros can be useful in certain cases
In most cases. Cannot think of anything beyond "Hello, world" that does not deserve a DSL implementation.
We've been doing this for at least ten years. Example: [1]
For someone who's convinced that DSL's are the silver bullet that everybody should be using, you don't seem to have kept up with the state of the art of the field much.
Macros are over engineered in comparison since they force the developer to learn a whole new section of the language with its own rules and own compilation lifecycle.
This is why hardly anyone uses macros these days and why most language are embracing the Groovy/Kotlin approach to writing DSL's.
The small amount of time it takes to learn Clojure and get used to its syntax is well worth it. Too bad not many workplaces are willing to similarly switch from Groovy to Clojure for writing tests. They even stick with the older Groovy version 1.8. Once something works, they won't upgrade.
Simplicity of the building blocks does not affect complexity of the resulting mess of code.
Look, Brainfuck have only 8 operators. It cannot get much simpler than that. Once you learn all 8 operators no new constructs require any learning. Does it help at all? No. You're stuck at a pathetic abstraction level.
Same with your functions. They're limiting your abstraction level, therefore making it impossible to make things simple. And your DSL example shows it in quite a dramatic way - it is a horrible mess and nothing but a horrible mess. It can be somewhat handy for the users, but the implementation is plain awful.
For example, this one: http://www.moserware.com/2008/04/towards-moores-law-software...
Or Nanopass itself, not just as a tool for building DSLs, but as an example of a nice and clean DSL (of course, if it could bootstrap itself it would have been even better):
https://github.com/akeep/nanopass-framework
Or everything you can find in my github repositories (username: combinatorylogic).
And, anyway, interpreters. Who in a sane mind can ever consider an interpreter?
Also, you obviously do not realise that macro-based DSLs are by far more debuggable than any monadic interpreter would ever be.
(I can send you examples of macros I've had to write, if you desire.)
Seeing you know what a logical phallacy is, here is one more for you: "if you don't like macros you don't know how to use them". Can you guess the name?
My question was not ad hominem. I wanted to see whether you have actually used the thing you are arguing against or instead just blindly praising something as the ultimate solution and thereby determine whether I should continue this discussion with you.
Can you comment constructively about the composability issue without resorting to ad hominem?
Do you even understand the idea if the macro-based DSL design methodology?
I guess you can have something as horrible as the CL LOOP macro in mind, instead of any properly designed DSLs.
No, I conculded that you have no idea how to implement macro-based DSLs from your remarks about composability and debugging. You cannot be so out of touch and still know something about the macros.
And, no, you did not point to a viable alternative. Monadic interpreters are complex, convoluted and very inefficient. This is an objective fact, not a matter of a taste.
Do not agree? Show me a definitive example of such a DSL and I will demonstrate how much simpler a macro-based version is.
Interpreters are inherently bad and there is almost nothing you can do about it. The only sane way of keeping an interpreter complexity under control is to use a single common trivial VM interpreter, write it once, never touch it again, and lower all your monadic DSL ASTs down to it.
Which makes this solution quite similar to the macro-based one (it would actually reek of Greenspun Tenth), but still much less efficient.