In the previous sections, I have avoided an important topic. What do I mean by "Expressive Eloquence" in the context of an artificial programming language? I am unable to base this concept on a sound theoretical foundation. But I know that you, dear reader, have an intuitive understanding of this fundamental concept. That is because you would not be reading this text if you weren't a code tuner. :-)
And as you are a code tuner, maybe you have pondered this innocent question: what is the meaning of "to optimize"?
I do not want to actually offer a definition here. Instead, I want to pursue an analogy with the chain of reasoning I laid out for the meaning of "to vectorize". Programmers do not normally think of machine language itself; the instruction set of a machine is a given invariant, an immoveable frame for everything that is done within it.
But if you assume a different point of view, you can follow me to a strange place where it isn't the language that shapes programs, but the programs shape the language. Seen from this point of view, there is suddenly a difference between the terms "optimizable" and "practically optimizable". And consequently, some instruction sets are better for optimizing than others, when seen from this angle.
I am unaware of any theoretical work, in linguistics, math, computer science or elsewhere, that tries to systematically construct languages for the kind of expressive eloquence that I am trying to catch here. Actually I am unsure that such a theory can ever exist. We know that a single machine instruction is enough for a complete Turing Machine; and we can imagine hypothetical languages that have opcodes for MSWORD, SAFARI, or GIMP. Neither extreme is of much practical value. The grey area between is large, and the successors of the ancient CISC vs. RISC wars are still being fought over that territory.
Anyway, this is the stuff I try to grasp with "expressive eloquence". Some languages are better for poetry than others, at least when it is about programming languages and code poets.