Every programming language consists of two parts: a basic set of given things, and mechanisms for defining new things in terms of existing things. These mechanisms are called "abstraction mechanisms". Abstraction mechanisms allow you to replace repetitive, boilerplate code with a definition of a named entity, and multiple references to this entity. They allow you to disentangle two separate concerns that are initially tightly entangled with each other in the code. This allows you to maintain the two design elements independently of one another. Once disentangled, each of the resulting entities can be reused in multiple contexts. The quest for better abstraction mechanisms is the engine that drives programming language evolution. -- me, in 2012

How about an abstraction mechanism for changing the abstraction mechanisms? How about applying that mechanism to itself? I actually just posted something that's somewhat about that: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1569653638037600

If you follow Dan's logic, you will end up with 2nd level LISP, which is devilishly hard to read. I am not aware of any program using 3rd level nesting, but perhaps some LISP fanatic can recall a case where it was needed. Most large LISP and FORTH programs were 2nd level. I am working in the opposite direction, trying to convert as much executable code into declarative, which is 0 level code; i.e. not executed but just "there".

I agree that's not the best place to end up, and the idea is actually to find / implement a more ideal representation on top of it -- probably something static or declarative -- and then the layer beneath it transforms it into the "real thing". That way the thing being specified / coded is 1st or 0 level -- and perhaps the best form reasonably possible for that thing -- and the 2nd level stuff acts more like a compiler or interpreter, which is 2nd level by definition. The benefit is that you break free of restrictions imposed by any one language or format or editor, because you specify it exactly how you want. This also blurs the lines between programming language, compiler/interpreter, user interaction, macros, and functions + data structures. Really these are all these same thing: specification, and the thing that builds / transforms it. The only difference is when & where that happens. Really it's all just functions + data, so my idea is to just put it all in the same place and compose / separate / invoke the different pieces in the right order.