Monday, February 26, 2007
Repurposing writing
Stern0888 (which has to be one of the best screen names ever--one thinks of street drunks predictiing the apocalypse but getting all the numbers off by 2) has posted a comment to last week's invitation to compare two stanzas, one "real" and one "counterfeit" and figure out which is which.
Sterno asks if Erica is repurposing existing writing.
I responded with a comment as Anonymous, because I was too groggy to remember my password. It's brief, but even briefer: Yeah. No. Sort of.
Tuesday, February 20, 2007
The Lady or the Machine?
What does it mean for a poem to develop an idea?
Here are two stanzas, one from the poem of a blooded author and the other straight from the machine--zero edits. Quick! Which one is the Machine's and which is “real”?
1.
The winged pen rests.
Cantilevering from the content, the other larger slab.
Accompanied by a dog or standing apart,
he hears it also.
We are at table.
Chronological tables, with rustic setting.
2.
Rusty as a rumour
Rustle because to
represent will be
to retreat
Respectable as a
restraint
Reciting recrudescence
Which then? Which speaks more theoretically—the resting pen or the failure of representation? One of these is real and so one would conclude contains or contributes to an idea. The other is not real. But is that because of the lack of the idea? Is the idea of content as scaffolding a better idea than the idea of deference to the restraint of form? Quick! Which?
I suspect that half of you will say “1” and the other half “2.” Both halves will have good reasons. The only table from which anyone can pick at the food of poetry is the table of time says one half. The only possible recitation is the recitation of recurrence—there is nothing new under the sun says the other.
Perhaps we should vote. That would end the question for once and all wouldn’t it—quality by consensus—and poetics as contest (or politics)?
Is there a politics of intention, then? The cynic’s refuge, everything reduced to dung (or dross), as if any power so acquired could ever be of matter. (Never forget that in Erica's meaning absolutely nothing at all, it is impossible for her to say just what it is she means—and so nothing she says could ever matter either.)
So which is it? 1 or 2? Which is sleight of hand and which is in plain sight, cited plain?
Framed in those terms, the way to tell then is to look for deception. The poem that draws a blanket of deceit up to its chin to disguise its nakedness would be Erica's and the one unashamed of nakedness would be some other, some real woman’s work. She professes a vision of the world. Erica (that little snake) conceals (and so confesses) a lie.
But it all comes down to a guess doesn’t it? And the idea of the poem then is in the guessing. It’s always in the guessing. So guess: 1 or 2? The lady or the Machine?
Comments welcome.
Friday, February 16, 2007
My department can beat up your department
Last night I attended one of Eric Raymond's talks. He followed his typical plan, 20 minutes or so on the announced topic (last night's was "Programming in the Real World"), then more than an hour of Q&A. A nice format--certainly evidence of a confident and accessible speaker. As always, Raymond was engaging and charming. (You know there's a but coming.)
But.... Raymond began by warning the audience (primarily engineering students) that their productivity (i.e., lines of code per day) was going to drastically decline in the "real world." (BTW: If it is true that the world is all that is the case, how is it that the university isn't "real"?) And why will productivity decline? Because of the "friction" inherent to communicating with users. Not only do users not know what it is they want, often they get what they want "dead wrong," he told us. (Other frictional impediments to communication as well--especially Brooks's n(n-1)/2 avenues of communication--this time among developers). I pointed out that students are constantly told that they need to listen to users but that the probability that a student will be offered (much less take) a course in such communications is pretty much 0. I also pointed out that it is completely unrealistic to expect users to know what they want. They are not experts in computational technology. (My view is that the responsibility for identifying needs rests with the technical team, who should be well-enough versed in the users' application domain to be able say to them, "Tell me about your business, and the problems you are having. Then we'll go back and make some recommendations on how (and if) a software application can be part of a solution.")
Raymond's response to all of this was that the field didn't attract people like that and recommended instead that programmers learn humility. Seems too many programmers are arrogant and that such traits of character interfere with communication. Programmers should try not to act like they know more than users, "Even if they do"!
There we go. That "We're smarter than anybody else" mentality that I've seen at both ends of the academy, in applied science and in the humanities. No wonder there is so little interdisciplinary collaboration. It's pretty hard to work with someone whose intellect you don't respect.
Hey guys! Guess what! A business analyst who has at the tip of his/her tongue the prices of a hundred mortgage products and a mental picture of their discount/rate matrix and another mental graph of the front- and back-end ratios that map to the matrix, along with corporate policy regarding asset and income certification and how every bit of this may be influenced by loan-sized pricing and LTV's and all subject to adjustment to constantly changing financial markets is actually pretty smart. And actually knows a lot. The first step in greasing away the friction of communication is to realize your partner's competence and to respect it.
Saturday, February 10, 2007
Witchcraft, indeed....
From an erika beta 0.0.1 test...
Witchcraft
Death and water retreat
Retreating death is swept death
I am cold but to retreat is
to part oiling death
To stamp is to storm
An open-mouthed char
Stamping sunshine
That I am worthy
To wear whiteness and witchcraft is
to wring whole
or glamour
To weld is to wander
a wise whisker
Dark
Of a practical man
Of sustenance
Droop or trust are a
development
Darkness and plumpness
doubt desolation
Disappearing
That death lies
I am second
To lie is to
eject death
Monday, February 05, 2007
I knew a guy...
I'm in the process of building a new Web page interface into Etc3beta. The current test interface just asks for a topic and then randomly selects from various input parameters the specific inputs it will use to construct a poem. Nick Montfort over at Grand Text Auto suggests an "Advanced" interface that exposes Etc3's inputs and allows a users to make their own selections.
That sounded like a pretty good idea, so I've been working on that. But Etc this time around is Java and so I did the "For dummies" version using JSP. But I'm an ASP guy, so that was a bit of a struggle. The advanced version isn't served well from a single form. It requires a set of inputs for each stanza a poem is to have. So I needed to save each set and then pass that over to the JSP page that will do the actually writing. So I decided to use JavaScript. Just save off the data into an array and then when the time to climax is nigh, shove it all into a cookie and retrieve it along with any relevant POST data in the composition page.
But I'm not a JavaScript guy either. I've written a couple of Hello World scripts, but nothing for production (or of any complexity). It's close to working, but boy-oh-boy, is it ever ugly--a brute force amalgam of html (and I'm far from an html expert as well), JavaScript, and JSP scriptlets. Ugly code is almost always an indication that the coder doesn't really know what he is doing. And that really shows here.
Debugging is really frustrating. I use NetBeans but NetBeans doesn't do syntax checking for either JavaScript or JSP scriptlets. You discover those during execution. But if a JavaScript function has a syntax error, the browser simply doesn't call it. It doesn't blow up the way I'd want it to. (At least in Firefox, the only testing I've done.) JSP requires a JSP server (I use Tomcat) and fortunately Tomcat does catch and report on syntax errors, but in an error page. And to make things ever more difficult, Tomcat wants Java 1.4 and I've used 1.5 for the Etc3 core. (Fortunately, all of the core is in a separate Jar which can be evoked with 1.5.) The problem is that my fingers want to use 1.5 features in the JSP pages, which aren't reported as 1.4 errors until the page runs.
Now, I know for absolute certain that somewhere there are better development tools for this kind of programming, that Tomcat can be configured to use 1.5, that the procedural code I'm writing to build xfer data could be better done with objects. But golly, I'm struggling with getting information out of a multiple-select html form list control. I'm not going to "waste" time learning the right way to do any of the really hard stuff.
Reminds me of a guy I once worked with. Really, really smart. I've seem him debug programs in languages he didn't know. And he could get anything to work. But he refused to be acquainted with anything like a design principle or to become fluent in any computer language. His philosophy (not unshared in the world of application development) was to learn just enough to make something work, build it as fast as you can, and deliver it to the customer. And (at first) customers loved him. But the code was pretty much impossible to understand, fraught with bugs, and extremely difficult to enhance. His code looked like my Etc3beta code. And caused his customers and his organization a lot of heartache.
Quite a bit of electronic writing is like this. Really smart folks leveraging computational technology for art, but in the absence of sound development practices. Sooner or later, as a community of artists, we're going to have to address this. Otherwise, the work will eventually languish in the vast swamp of mediocre programming, like Etc3beta's Web presence.
But until we do, I guess we'll just keep saying drive on....
