Monday, September 25, 2006
Reading computationally expressed poetry
As computationally generated texts get better (and they are), at some point we have to begin thinking about an appropriate critical response. Just how does a critic engage with a non-authored text? What constitutes quality in an ALG text? What shape should this incipient tradition take? Who gets membership? Who gets shunned? How will we know which texts by which machines get to be included in anthologies? Who gets to decide? For that matter how is it to be decided (excellent evasive use of the passive voice there--there's hopes I can yet get to the humanities table) which texts make it into the academy as line items in syllabi?
Of course with no author to belittle, the critics job becomes ever so slightly harder: Pretty hard to deconstruct something that can't even know what the logos is. Or to psychoanalyze the hidden symbols belching from the machine whose mother, the math of the chip, must remain forever uncastrated. Or to show how mechanical texts are exemplifications of a a male dominated social system and thus instruments of rape. Or how the machine makes manifest the commodification of the arts, falling down hard on the capital side of the class struggle (actually, you might be able to make that particular case--I bet someone will try).
I would almost bet next month's salary that ALG will resurrect an interest in reader response criticism. We better get ready. A great place to start is with Norman Holland, the original reader-response guy, if for no other reason than this little snippet from one of his early essays, "Re-Covering 'The Purloined Letter,'" in The Purloined Poe, pp 310-311, in a paragraph engaging Marie Bonaparte's ( a student of Freud's) analysis of "The Purloined Letter":
"The struggle between Dupin and the Minister D-------- is an oedipal struggle between father and son, but of a very archaic kind, a struggle to seize not the mother in her entirety but only her penis, only a part therefore. A Bone-a-part, I suppose."
You just gotta love a guy like that.
Friday, September 15, 2006
Pink paragraphs
Last night I attended a reading by Elizabeth Willis, this year's inaugural reading in Temple University's Poets and Writers Series--part of its Creative Writing Program. A phrase from one of Willis's poems has been rolling around in my head ever since (even dreamed about it): "Pink paragraph."
The questions are obvious: How is a pink paragraph different from other paragraphs? Is a pink paragraph a feminine paragraph standing in contrast (or resistance) to a male blue paragraph? (Or would a blue paragraph be a vessel of despair or maybe a manifesto of prudery?) Is a pink paragraph a diminution of a red paragraph, sublimating that red paragraph's torridity and lust into a secret, sedate desire? Is a pink paragraph a liminal stage between black and red? The highlighted word of God?
Less obvious is that language used this way is a step on the stairway of surprise and, for now, out of the reach of computational poetics. We can't model it. What would we look for? Denotations of compositional structure preceded by a color adjective? Any adjective? Or maybe a color preceding a conceptual noun? But isn't a paragraph a concrete thing?
We can't copy it--that's plagiarism. We might use it for inspiration, directing our digital friends to base a work on it. But that's derivative, and what we want is to be original. And that's the ever-present problem we haven't solved: The reduction to code of the features of the creative moment.
Monday, September 11, 2006
Erica and 9/11
Friday, September 01, 2006
Avoiding the 'g' word
Java has a goto keyword, but it's not implemented. Reserving it prevents programmers from declaring variables named goto (one imagines a default class Goto that works like the goto-guy, used as an ultimate fallback, with a declared instance: Goto goto = new Goto()). Sun is hedging when it reserves the word, just in case they decide to allow it in some future Java release--a bit cowardly it seems to me.
Now there's lots of folks who think you should never, ever use a goto statement, that any program construct can be written using structured programming concepts. It goes so far that I've seen textbooks for langauges that do have goto whose authors declared that they refuse to explain to students how to use it--language Nazis, really.
Of course all of this goes way back to COBOL's heyday, when the only real way to branch (in most languages) was with the goto. And I'm humble enough to admit that I'm old enough to have coded a lot of programs in such a language. The trouble was that these programs degraded over time into jungles of intertwined logic threads. Go here, go there, then go back to here, then go somewhere else. You'd often find programmers crouched on the floor with pages of greenbar all around them and drawing lines in different colors from statement to statement trying to find out just what the original author had in mind.
A bad thing for sure, but you can't eradicate a word from a language by declaring it evil. Goto will always persist in the spectrum of jmp mnemonics at the assembler level. And it will always be useful.
One really good use: to provide a single point of cleanup in a method. For example, say you have a fairly complex function in which you first allocated some resource and then use calls to that resource to initialize a state and then execute a couple more calls to utilize the resource. Being a good little programmer, you obsessively check for error conditions, so you can abort the function if anything goes wrong. But here's the problem: Before aborting, you have to clean up the resource. An easy (and easy to read( way to do this is to place a label at the end of the function, with a name like BAIL_OUT:. Put your cleanup code there and a return. Anywhere, you encounter an error or instability, code goto BAIL_OUT. Easy, clean, efficient, readable, and a lessened probability of error.
Java recognizes that sometimes structured techniques are a pain in the neck, as evidenced by its syntactic feature of labeling loops and then breaking from a labeled loop, rather than setting switches (the structured way) and then checking them on every iteration. But it draws the line at goto.
Arguing over goto is like arguing over fuck. In my view, words exist to be used, if only rarely. Goto, like fuck, ought to be avoided in most contexts, but when appropriately used, it can be a powerful linguistic formulation.
