Code Poems, how I came to write them.

Among many failures in my life, my involvement with programming computers is a long standing issue. Basically I can do it, unlike some, might have been good at it, but even though I enjoy the results of other people’s work in cutting code, I do not desire to work in that field. The idea of that information technology still, however, inspires me.

One inspiration that comes from the format of programming is to play with the declaration and calling of functions (and how arguments or parameters are passed to them) in poetry.

Now, before I explain and example that, I’ll briefly refer to other possible examples, but are not what I mean when I talk about “code poems”.

I am not referring to using code to make poetry or generate word salads or hashtag clouds, like wordle, nor Web 1.0 style generators, particularly those pomo essay generators.

Nor mash-ups like: “My intial project proposal for IDAT 210 was to have poetry decided by the feeds from the Arch-OS system.”

And yes I seemed to have missed the whole Code is Poetry thing, circa 2005. It’s a nice metaphor but I’m not claiming code is poetry here either.

No, what I did was an example of literary pseudocode. Very, very pseudocode. (All code here in this post is pseudocode BTW.)

It was based on some familiarity with C and C++ programming.

A function is a subroutine of a program that does stuff, i.e. manipulate data, and reports back on its success. What a function does is defined by a declaration, i.e. where what it does is described. This declaration includes what information is to be passed to it, directly or by reference (by address rather than value) i.e. do ABC at XYZ.

Like so:-

 int functionDO (ABC, XYZ)
          { do ABC at XYZ }

Above is functionDO, it takes arguments ABC and XYZ, does ABC at XYZ and reports back with an INT (integer).

I took this basic form and applied it to some experimental poetry, using the idea of passing arguments or parameters to functions. (Fiction needs conflict so I’ll stick with arguments.)

In particular I liked the idea of an ideal reader parsing a series of functions, thus building or compiling a story that would run in their head, like a program in their fleshy computer. I imagined the reader as a bit like a pseudocode pseudocompiler, turning the list of functions into a computer program which would run on a particular machine, a particular architecture of computer. I.E. They would interpret it from their own perspective.

But where, of course, due to some serious recursion issues on occasion (in some code poems the dataset is the compiler because the fleshy computer is that which interprets the code and does the passing of arguments which then feeds the output of this process back into the process.) It can get complicated as I was trying to write both by imagining some fleshy compiler taking hold of these functions and (therefore) trying to limit their (reader’s) interpretation of them. I was trying to both allow and constrain the multiverse of possible interpretations.

That was the original idea, the problem I wish to solve. This makes it experimental poetry, like modern art, the creativity lies in creating both the problem and the solution.

In this idea, as problem/solution, I was going to use lots of functions initially, but actually, in writing code poems I called on the function DATE almost entirely. For I felt most less-than-ideal readers would take the function DATE to indicate a journaling or diary activity, even if they had no idea what a compiler is.

This DATE function, thus defined by the writer (me) guessing what readers might do, was then supplied with arguments. These arguments were words which the less-than-ideal reader would have some strong connotations with, or reactions to.

date:(good, intentions)

An example which may bring up in the reader’s mind a certain pop song by The Animals.

The logic of the problem (using functions) would create a new space in experimental poetry, a new dimension, and I would limit the ideal reader’s response by calling on emotional attachments, as raised by the arguments the functions passed. The arguments were emotionally loaded. These emotional connotations would limit the reader’s reactions to the text, and/or give them leave to overcome their problems of engagement with the new form itself.

My ideal reader/writer then works through those references in turn, the written words in the code poem following the function DATE: are the data log of that parsing and manipulation by one of these imagined ideal readers. The product that an actual reader (who is not the writer or creator of this function calls or code poems) reads is my imagining of that process as I write it down.

Hopefully other reader/writers may find it of interest, even if they are less than ideal.

Feel free to write your own.

UPDATE 2012-03-29: Confused? Check out apperception under epistemology, where apperception is “the introspective or reflective apprehension by the mind of its own inner states.”

Examples

There is an excerpt of an old 1997 piece of mine here. (Note: Sentences beginning ‘•’ are spoken aloud or communicated in some way (tweeting?). Sentences beginning ‘.’ are not spoken or communicated. This is a form conventional to the work this excerpt is from, and not to ‘code poems’ of mine per se. The entire work is availble as a PDF .before Country )

I’ll be posting a couple of newer code poems here on formeika soonish. Indeed this entry is just background for those.

__________ ||| ____________

When you read a particular format, poetry like haiku, or genre novel like Science Fiction or Detective, you understand the elements and what to expect because you known what literary function has been called, because previously it has been declared by convention or time-honoured tradition.