While two people can exchange ideas in ambiguous language, in programming, code is translated to machine language, which has no space for ambiguity, color or connotation. Even esolangs that thrive on ambiguity ultimately translate into some kind of (strictly denotative) machine code at the bottom. As part of this translation, there’s usually a step where an abstract syntax tree (or similar data structure) is generated, to make sense of the program. Let’s say a program has this line of code:
print(4 + 5 * 3);
This is the “concrete syntax” of the language – the actual words a programmer might type. It also contains the classic example of ambiguity: whether the addition or multiplication operates first. This ambiguity is resolved in the construction of an abstract syntax tree (AST), a data structure which rearranges tokens (base units of meaning) of the code, according to the rules of the language, taking in account order of operations (in nearly all languages, multiplication is “lower” than addition, so executed first):
Now we can see that 5 * 3 is resolved first, added to 4, sent as a parameter to the print command. We can think of the abstract syntax as the logic of the program stripped of its symbology.
Most programming languages strive to make its behavior as clear as possible, so transparent concrete symbols are selected. But esolangs often complicate this. For instance, the language ActiveEmoji, which allows one to write Ruby using emoji:
Underneath, the language is straight Ruby. Since it is implemented as a direct mapping from one vocabulary set to another, we might think of ActiveEmoji as an esolexicon rather than an esolang: only the vocabulary is “esoteric.” Or LOLCODE, the much-maligned esolang which is a straight procedural language behind lolcat phrases (and perhaps would have been more successful if implemented the way ActiveEmoji was: as a direct substitution of symbols). Acme:Bleach is a set of vocabulary for Perl allowing one to program Perl using only whitespace – this is also simply a mapping (compare to the Whitespace language, for instance).
In contrast are the behavior-oriented esolangs. such as Whenever by David Morgan-Mar (discussed recently). In Whenever, the programmer has little control over the order in which lines of code are executed. Or Fractran, where commands are encoded as fractions. Each of these have bizarre logic. Generally speaking, this type of esolang is more interesting to esolangers; they offer something more than a strange face on the same old code. They are also less accessible to non-programmers: it’s easy to get what is special about the visual language Piet (also by Morgan-Mar), Whenever takes an investment of thought and a comfort with programming to understand (and it’s a lot more interesting if you’ve actually played with it!).
That said, the complexity of vocabulary-oriented languages can easily be extended beyond what is done with the esolexicon / straight substitution examples above. I called Whenever a “behavior-oriented esolang” as opposed to “logic-oriented” because languages like Piet show the potential for languages designed around vocabulary to use symbology to introduce logic of its own, or to play on aspects of human communication that are otherwise overlooked in programming.
Hello World by Thomas Schoch for Piet (2002)
In Piet, the color of pixels in an image determine commands. And it is not the color itself, but the change in color (both hue and lightness have meaning). Furthermore, code flows in multiple directions, depending on syntactic markers (building on the Befunge language). Piet is a great example of how complexity at the concrete language level – and the possibility for complexity of signification – can make for a fascinating language, even if behind that set of symbols is a simple, stack-based procedural language. Piet’s image-based code creates an opening for the ambiguity of imagery – the ambiguity of language – which can’t persist at the AST level. Images function semiotically and affectively, and in the case of Piet, each image carries the additional meaning of the code it will translate into (acknowledged in the imagery of some of the best Piet programs).
Other vocab-oriented languages comment on the use of symbols themselves, such as ‘Alb (discussed here), which uses Arabic, exposing how ingrained is the default of Western-dominated language in programming. Shakespeare, a language in the form of stage directions and dialogue, is a powerful early example, making code ridiculous (while perhaps building on the intertwined histories of encryption and computing). My Velato and Light Pattern build on Piet’s example, using music and photography symbiotically with code.
These strategies give vocabulary-oriented languages their power: ambiguity at the concrete level, critique of signification, and tension between the purely denotative below with the gesture and affect at the surface.