The esolang Shakespeare, created in 2001, was among the first to make code resemble prose. It wasn't for the purpose of clarity -- to explain the behavior of an algorithm in simple language -- but rather to do the opposite: prose to hide the algorithm's computational nature in a dramatic script. Karl Hasselström and Jon Åslund, two bored students, built the language to fullfill an assignment for a Syntax Analysis class. In their language, adjectives with positive and negative associations correspond with positive or negative numbers. For the first time, a prose-like programming language used the emotional quality of language as part of its calculus.
While Shakespeare brings aspects of human communication that are ordinarily secondary in code into the foreground, its creators opted for a broad comic approach, with over-the-top language and ridiculous exclamations: "Speak your mind!" prints a single ASCII letter to the screen.
Poet Will Hicks was inspired by the concept of the language, but found its execution lacking. As he tells esoteric.codes, "When I originally encountered Shakespeare, one of my disappointments with it was how much the algorithmic aspects of the language intruded on its possible artistic expression (e.g. 'Thou art as sweet as the sum of the sum of Romeo...')." .... "[it] tends to become tiresome after the third 'Speak your mind!' "
His answer is a series of languages called the Esopo project. Instead of dealing with specific vocabulary like Shakespeare, Hicks uses constraints drawing mainly from the formal rules of poetry. The name derives from esolangs and Oulipo, the Paris-based experimental writing movement frequently invoked on this blog. As opposed to codework / code poetry that mix machine and natural languages (such as that of Mez Breeze), Esopo languages are usable languages, a Turing Complete poetic system.
In AshPaper, the first Esopo language, elements of poetry become commands. Alliteration in consecutive words is a goto statement. Rhyming with the previous line compares registers and pushes to the stack a number corresponding to the number of syllables in the line or its predecessor (depending on the result of that comparison). Like many other esolangs including Befunge-93 and Piet, AshPaper is a stack-based language, opting to add values to the stack or manipulate them there, and thus avoid working with named entities like variables, which can be complex to represent when the signifiers of the language are not necessarily textual themselves, but very often structural.
I developed a lexicon in which particular tools from the poet's toolbox would correspond to algorithmic operations, but I also tried to ensure that there were multiple ways of building any particular operation. A "for loop" might be constructed with end-rhyme and a particular meter or with an appropriate sprinkling of similes, for instance.
Here is a factorial program in AshPaper. It is a recursive algorithm, and the number of syllables in the title of the poem is the number to factorialize:
other woodwork
like a folding
up, a
branch-work growth
of
AshPaper trees come together
as we demand
perfect edges, impossible creases
a Scream of roots
toe-curled
inward
gro(w/a)n
past lines of pebbles, into wellstones
cracked. broken.
perfect edges impossibly creased
what's left of that?AshPaper is the most developed language for Esopo, with working compilers or interpreters for Python, JavaScript, and C++, and one for assembly in the works.
A very different aesthetic can be found in the Esopo language Correspond, which is more engaged with textual content than with the formal aspects of writing. It is an epistolary language, inherently personal. Its virtual machine has two registers: You and Me, along with two stacks. Using "I" or "me" in a sentence makes R_ME the active register, while "you" makes R_YOU active. "We" or "us" checks if R_YOU == R_ME, and if so, executes an instruction. "Love" also performs that comparison, and re-executes a subroutine if so.
Here is an example program, which multiplies the value sitting in R_YOU with R_ME:
Dear Reader,
I do not expect a reply. What did I describe last? Sand and dust on a white
table. Who would have responded to that? I can't even remember why I wrote
about it. Does it still matter?
Always,
Your Writer This leaves the connection between the gist of the letter and its computational performance to the poet writing the piece, avoiding much of the awkwardness of code poems that use commands simultaneously as natural language (metaphorically) and code (directly).
Currently in the works is a new Esopo language called Emily, based on Emily Dickinson's writing.
One of the things which I find particularly compelling about Dickinson as a poet is the way various poems leverage the same poetic rule or constraint to markedly different effect. In one poem, the staccato emphasis of her iambs will magnify the impact of a particularly bleak word; in the next it will draw together euphonious syllables to accentuate a sense of harmony. So, my original thought with "Emily" (the language) was to explore the varied regularities of her ouevre by making them the basis for available algorithmic expression. With that in mind, I forced myself never to use the same poem two times in a row while developing the language. If my purpose was to discover commonalities hidden behind apparently significant difference, I knew that focusing on a particular poem or set of poems would lead me down the wrong path. Furthermore, I especially wanted to avoid the 'canon' of commonly-studied poems to keep from getting stuck in widely-accepted notions of her poetics.
While his research toward the Emily language started over a year ago, it is still in the works, showing the consideration that goes into developing a project for Hicks. His original specification for the language was based in part on works that had been contaminated by (mostly male) editors, who had stipped away some of the idiosyncrocies of her writing. Hicks decided it was better to start again from the beginning, with a more careful, scholarly approach from original sources.
This and the other Esopo languages show how esolanging can function on a much deeper level than joke languages like Shakespeare or Rockstar, briefly a top project on Github.
With all of the Esopo languages, my goal was to develop constraints to push programmers toward poetic or literary expression without excessively limiting the content of that expression (or indeed the algorithmic expression of the programs they created).
The rules of each language are simple enough to construct programs that are less revealing of their programmatic nature. For Hicks, everything depends on the subtle craft of making the constraints:
Crucial to the aesthetic success of this project is a careful consideration of the relationship between specific linguistic constraints and their corresponding algorithmic instructions. What should enjambment signify in the world of algorithms? What command ought to correspond to end-rhyme? These relationships certainly should not be random, or else the structure of the resultant texts will not meaningfully reflect the structure of their signified algorithms. But neither should these relationships be stultifyingly illustrative.
The beauty of Esopo languages are that, while the works explore the aesthetics of the language, you can read them as poems without necessarily knowing their computational nature.
