Ironick

The Essence of a Programming Language: A Language for Describing Change

I came across this great post regarding the pros and cons of DSLs (Domain Specific Languages):

Which brings us at last to the question: what is a programming language?

I suspect that a programming language is really a framework for dealing with change. The reason that we have general purpose programming languages (instead of a plethora of DSLs), the reason that SQL has been so successful, the reason that Java has been so successful, the reason that Design Patterns are necessary to adress [sic] recurring but-never-quite-the-same problems, is because change is a structural problem of software development.

To cut to the point: a programming language is not simply a means of solving some particular problem. A programming language doesn't define the solution to the problem, it defines how the solution will change over time. This is the categorical mistake that so many make when criticizing languages: the expressive power of a language is not the measure of a language's ability to model a problem domain, it's rather the ability of the language to control changes in the problem domain. This is ultimately why DSLs and their ilk may be more expressive than a general solution, and still possess less expressive power than a general solution.

I think this is a profound insight. The analogy it brings to mind is how the general purpose language of English and Mathematics work with regard toDSLs. In English, the  DSL's of law, medicine, biology, physics, etc. all share the grammar of English (as enabled by the function words of English (prepositions, articles, etc.) The same goes for theDSL's of mathematics: topology, calculus, statistics, etc. Although all are quite DS, they are all embedded in the general purpose language of mathematics. In both the case of English and Mathematics, it is the general purpose "matrix" language that enables change within thequasi-DSLs embedded in the matrix language  and that enables new quasi-DSLs to be created within the matrix language.

Trees and Instruction Sets

Brian Beckman has some interesting observations on tree (recursive) and list (looping) representations of programs:

For some time, it was popular to experiment with VMs (virtual machines)that accepted programs represented as trees or graphs or relatedalgebraic structures. ...
However, most workers have completely abandoned this approach and goneback to instruction sets as the preferred representation at the VMboundary. ...
Since trees and their relatives are an inherently recursive datastructure, feeding them to the VM means that the VM needs to do thepedestrian step of boiling off recursive definitions before it can getto its real job. ...
Recursion is great for describing things, but lousy for executingthings. Describing things is the compiler's job, and executing thingsis the VM's job.

Sounds like Herbert Simon's old descriptive vs. prescriptive dichotomy. My question is: why not send both to the VM? Then the VM can execute the instruction list immediately, but if the program needs to reflect, the tree is right there. (Of course, the instruction list would have to be (partially) recompiled if the program modified the tree.)

Also, isn't Ruby still directly executing trees?