Closure (n): The act of closing or shutting

In the other course I’m taking this term– Paul Kameen’s core course in rhetoric which is focused on referential language– we’re currently reading through some essays and works from poets in the 1970s and 80s, namely from the L=A=N=G=U=A=G=E movement. It was/is a movement that foregrounds play, collage (material collage, literal cutting and pasting, as well as later digitized versions and other means of appropriating texts from other sources), strangeness, and a deliberate disruption and intervention into the typical modes of close reading. Above all, the poets from this movement were invested in troubling the relationship between reader and writer, in calling to attention the reader as an equal if not majority maker of a text. Such works resist “a reading”.  In Lyn Hejinian’s exceptional essay “The Rejection of Closure,” she writes:

It is not hard to discover devices–structural devices–that may serve to ‘open’ a poetic text, depending on other elements in the work and by all means on the intention of the writer… the ‘open text,’ by definition, is open to the world and particularly to the reader. It invites participation, rejects the authority of the writer over the reader and thus, by analogy, the authority implicit in other (social, economic, cultural) hierarchies. It speaks for writing that is generative rather than directive. The write relinquishes total control and challenges authority as a principle and control as a motive. The ‘open text’ often emphasizes or foregrounds process, either the process of the original composition or of the subsequent compositions by readers, and thus resists the cultural tendencies that seek to identify and fix material, turn it into a product; that is, it resists reduction (88).

Reading Hejinian and then also Ramsay and Underwood and Sellers at the same time has me wondering, if algorithmic criticism serves to open up new critical readings across literary texts, what is the role of the “reader” of its outputs? On the one hand, the reader is maker. The reader/coder designs (or appropriates) an algorithm with which to sort through a mass of textual data, and determines what that algorithm is meant to do. It re-reads the data to assign and sort through tokens, making sure the human sense-making system of word combinations are represented by the data (e.g. “high school” becomes a bunch of “high” students at “school” if we’re not careful to assemble the singular term). The algorithm designer reads the world as much as she  reads the data, but the design of the thing makes strange before it makes sense. The reader still has to make “value” of the repetitions. To ask what it means.

This version of reading strikes me as quite similar to the request Hejinian is putting on the reader to bring themselves to the text. Her process might be idiosyncratic and not automated in the same sense that a machine algorithm is, but her texts could read like a computer-generated recombinatory text. Hers is not a poetic that is based off of “natural language”. Take this moment from My Life:

The continent is greater than the continent. A river nets the peninsula. The garden rooster goes through the goldenrod. I watched a robin worming its way on the ridge, time on the uneven light ledge. There as in that’s their truck there. Where it rested in the weather where it rusted. As one would say, my friends, meaning no possession, and don’t harm my trees.

Hejinian verbs the noun “nets,” and describes the robin’s search for food as “worming,” and gives “time” a physical location (read, perhaps, the passing of the light by the shadow of the ledge tells us the time… but that is too many words and perhaps not what is “meant”). The play with “there” and “their” in sonic spheres. The weather as something that one can be “in” apart from what happens to us. This is not natural language in the same sense that other texts are, even the poetic works of the time period Underwood and Sellers are looking at. If we determined the frequency of light to be quite common it is still “unreadable” as a figure or trope, as only context determines these things and even then the context doesn’t save you with the Hejinian poem. The language would probably flag as not latinate and more common. There’s plenty of idiom if you could have the code look for such things, but that can in no way signal a desire for “universal experience”.

In short, while perhaps in the window that Underwood and Sellers are analyzing some kinds of “closure” is possible, but feels to me to be too limited in terms of their conclusions. In the sense of most of these algorithmic criticism machines, they seem to me to be mechanisms for opening up the text to the level that Hejinian hopes her works have from the outset, but then the critic’s aim is still to close them down again. Perhaps Hejinian would say that these are new technologies at all, and that it’s actually a responsibility of the writer (or algorithm designer and executer) to leave a text open to such participation from the reader. Sense-making is not unlocked by the texts themselves but by the interaction between a text or texts and its reader. This is not a new concept. Of course we all participate in texts as readers, but as with so much we’re thinking about in this class, it’s a matter of scale. The Hejinian poem demands much more of us. These algorithmic critical programs demand much more of us. How, then, do we amplify the openness and work with the results of these programs without succumbing to reading the output through critical modes that “seek to identify and fix material, turn it into a product”?

Program (n): a plan or scheme of any intended proceedings (whether in writing or not)

“Any reading of a text that is not a recapitulation of that text relies on a heuristic of radical transformation,” writes Stephen Ramsay. Yes. so much yes. In part, this observation is what research into analog and digital procedural making (e.g. making things from others’ texts) hinges on. Even when we only use our eyes or other technologies of reading (like highlighters, or the boxing tool in Adobe PDF Reader), we are selecting texts and isolating words and phrases that appear to our minds to be the keystones of the text we are attempting to “understand.” We all have our programs of reading. Some of those programs are more involved or more constrained, or are more deliberate than others. For example, when I’m reading I almost always write down what I perceive of as key terms in the margins next to particularly meaningful passages. My key terms might not be exactly the author’s, and they might be mine but not anyone else’s key terms for the same article. As I look through the key term results for my data set for “machinic” I am struck by the knowledge that these key terms are author-generated, while the other data represent repeated terms as computer generated, and include things like “of the.” But when you think of the rhetorical moves necessitated by using “of the” a reading emerges. Someone is trying (at least in one portion of the thing) to compare or narrow. We need not know what is on either end, we only need to reflect on how such a combination of tiny words is used. Certainly the program finds what the eye is not capable of and the eye is interestingly fallible, but largely the programs Ramsay discusses and the program JSTOR has created to do this search for me are matters of scale and redirection. Either version — me scanning the results and coming to a reading just from that glance, or the programming we’re about to write to deal with these data — are programs of reading.

Fortress (n): a fortified place

DFZones

This is my Dwarf Fortress area. I have made some zones, and I made a burrow and had my people meet there. They have yet to do any of their jobs, but at least they are in a burrow.

I downloaded Dwarf Fortress fine and it ran immediately. I chose the version with music, and I’m glad I did. It is lovely music. It is just about the only thing that is calming with this whole process. Here’s a recreated dialogue between my beau and I, he-who-used-to-be-a-programmer-and-plays-Dwarf-Fortress:

Me: “I understand that each of these symbols means something in terms of the terrain and what is underground.”

Tim: “Mmm hmm.”

Me: “I understand that I cannot ask my dwarves to do anything, I have to designate jobs for them and then they’ll do things in their own time. I understand that I have a wagon and a cat.”

Tim: “These seem like good things to understand.”

This is going to be difficult. Conceptually I think I get it — you set up some tasks and you let it run. I like city-building sandbox games, and parts of this are like that. You need people to do certain jobs and places for them to do them. There are unpredictable events that are outside of your control. My issue is that it’s just overwhelming — there seems to be an options menu for everything and those menus are not intuitive. Sometimes I use the arrow keys and sometimes I use the + or – and these are the keys on my number pad not the same ones above my qwerty keys. Sometimes I have to use shift to get to the capitalized version of a letter. Red letters tell me I need a manager, but when I assign a manager I still cannot assign jobs. Three hours in and my people still aren’t doing the jobs they’re capable of doing. I’ve zoned some things, and I’ve made a burrow (see above… my dwarves are hanging out in the burrow because I assigned it as a meeting place… at least, I think that’s why they’re all there). I can’t remember what I marked the other zones for.

My favorite part of the game so far, apart from the music, is the complex biographies for each character. Under some menu (view unit?) I found an option for “Thoughts and Preferences” and there is the individual story that read somewhat like a terrible online dating profile. Uzol Bertorad, coined “Uzol Earthbodies” is 88 and “always tense and jittery” but he “doesn’t mind wearing something special now and again” and, sadly, “needs alcohol to get through the working day” (I’m not sure I’m even gathering berries let alone making ale). When reading the “Dwarven Epitaphs” piece by Boluk and LeMieux I was struck by the narrative complexity of the program that is just simply invisible from first glance. I “played” for about two hours  and then went to the readings, hoping they’d give me the inspiration to return and try out some other options. The game they are describing sounds amazing! Based on the fantasy short stories of Zach Adams and moved into game mechanics, the way the game writes a history is absolutely fascinating, and the failed narratives by players are told as dramatic encapsulations of the inevitably epic and odd deaths of their dwarves sounds like an ideal form of potential literature. But for the moment I’m overwhelmed by the attention to detail (is that what it is?) of the mechanics accounting for geographical details and world situations. It’s exceptional, but near un-game-able. Because I know Tim enjoys the update notes, I found them in the Release Notes file in the download folder.  “Stopped random creature proboscis from sometimes messing up poison attacks” and “Made removal of trees check building/bridge/machine stability” are a couple of my favorites.

Boluk and LeMieux describe Dwarf Fortress as the game version of future historical models recreating our lives, “dwarves live within us, around us, and without us–in vaccines and antibiotics, in mechanical and computational systems, and in the geological and cosmological happenings of the universe. The role of the human, then, is not to play videogames but to produce metagames” (150). I’m excited to find out what history my game will tell… if I can ever get my dwarves to do anything in the first place. Maybe not doing anything is what is keeping my six dwarves alive (I have no idea what happened to the 7th… I missed that plot point, or can’t recover it because I’m not sure what menu it lives under…). Is Dwarf Fortress the game an impenetrable fortress itself? To be determined.

p.s. This post ended up longer than intended… I had been thinking this was my week for a substantive post but we’re all blogging this week — so I guess I’ve just been thinking about it too much for a quick update!

Bot (n): An automated program on a network (esp. the Internet), often having features that mimic human reasoning and decision-making

This was the second (third?) time around in bot-making for me, and I was struck by how much just a little more programming experience makes the task so much less daunting. It helped that the tutorial was put together in such an easy to use platform. Coding and hosting environments are still elusive to me (are there free versions? How do we get access to them?). The last time I created a bot a couple years ago (Casual Observer @FlyOnTheWallBot, which is broken right now because Twitter changed their OAuth protocols and I didn’t realize it), I wrote it in Google script so that I could run it from Google Drive without worrying about it. But Google script feels much less intuitive than Python feels to me now, and seems to have much fewer resources in terms of existing libraries to import. When we talked about how to search Twitter and use its results at the end of the workshop, I was awed at how much easier it would be than the script I wrote (with lots of help from web searching, my c.s. boyfriend, and appropriating parts of code from other bot-markers). Certainly I’m nowhere near pro-status when it comes to bot-making, but I feel like I have a lot of ideas that could viably be realized with a bit of work and time, and that’s super exciting!

Mechanics (n): the procedural or operational details (of something)

2015-09-15_18.36.39

In another Bogost work, Alien Phenomenology (2012) he presents the notion of philosophical making as what could be akin to Carpentry “to do carpentry is to make anything, but to make it in earnest, with one’s own hands… carpentry entails making things that explain how things make their world. Like scientific experiments and engineering prototypes, the stuffs produced by carpentry are not mere accidents, waypoints on the way to something else. Instead, they are themselves earnest entries into philosophical discourse” (93). This prior argument from Persuasive Games (2007) emphasizes the gamer, interactor, critic, and reader of the video game in order to elevate games to the level of expressive and persuasive power of literary and other media, but I couldn’t help but feel the maker decidedly left out in this reading of Persuasive Games (it’s the second time around for me). If in the Aristotelian sense rhetoric is related to our capacity to percieve the “available means of persuasion” then Bogost is putting games on the table as an available means of persuasion, and rightly so. As Bogost posits, “procedural rhetoric is a subdomain of procedural authorship; its arguments are made not through the construction of words or images, but through the authorship of rules of behavior, the construction of dynamic models. In computation, those rules are authored in code, through the practice of programming” (29). Rather than focus on the programmer, however, Bogost reads via the lens of the gamer or the critic, which he more than once acknowledges. “Procedural rhetorics,” he writes in his concluding chapter, “expose the way things work, but reflection creates and prolongs this process. Criticism is one aspect of the reflective process. But criticism requires formal discourse, often limiting itself to the academic and cultural elite. More generally, persuasive games can produce discourse in the general sense, like the blog conversations that crop up around the Dean game” (334).

I figured that today I’d think somewhere between Bogost’s two arguments, between critic and maker, where individuals who have a certain level of “procedural literacy” (re: Chapter 8) turn the rhetorical tools of the game toward their own uses, often to subvert the dominant expressive narrative of the base game. It’s procedural rhetoric by appropriation — and I think why I was tempted to add “mechanics” to our list in discussion of code and programming last week, because such work necessitates an understanding of the code at the level of exploiting game mechanics created through the code. This is perhaps especially possible in sand-box style games, like The Sims, which Ada described in an earlier post today. Just search in YouTube for any emotional challenge and you’ll find a Sims animated narrative telling that story, like the results for “bullying” demonstrate, for example. There are also narrative videos of players picking up prostitutes in the various versions of Grand Theft Auto (a component of the procedural rhetoric left out by Bogost, as he chose instead to focus on fast food and health in GTA San Andreas… ugh), either as chosen Let’s Play video headings or in montages (I implore you not to read the comments section on these GTA videos).

Games with simple mechanics like Minecraft leave it open to the player to create his or her own narrative, deciding what kind of world to build and how sinister or kind that world might be (toward the environment, for example). This kind of openness leaves room for modding (game modification), where programmers can edit or add portions of game code to alter those mechanics or add new interactions, which is especially vibrant with games like Minecraft. Game packs with certain selections of mods are also often put together with the mod “Hardcore-Quest-Mode” which uses a quest book to set up a narrative and guide the player through the use of the mods. Many of these questing packs start with some type of dystopic setting, changing world-gen to create desolate worlds that players have to rebuild with plant-based resources, or build consequences into a game without much consequence in its base game (have a gander of some of these packs). The persuasion then comes not from the game’s original programmers, but with those who can read and make new mechanics from existing capability of the games, which can then be interacted with by other players.

As I continue to think about programming literacy I feel a personal and intellectual tension. On the one hand, I want to learn how to code so I can make academic work with and through digital means, but on the other hand appropriating and exploiting existing program mechanics can generate productive and expressive avenues for users and thinkers, which requires procedural literacy but doesn’t necessitate programming knowledge, per se. I wonder what’s more important for the general population — being able to read and understand how code is impacting the ways in which we interact with programs on the web and otherwise enough to make/appropriate/exploit those mechanics for one’s own expressive purposes, or learning enough code to invent from the ground up? In many ways I think the appropriative version is more exciting — just give people discursive tools and they’ll act with them. It also takes away (perhaps) some of the intimidation factor of learning and keeping up with ever-evolving programming languages and tools, which is a good thing, no?

 

Code (n): “Any system of symbols and rules for expressing information or instructions in a form usable by a computer or other machine for processing or transmitting information.”

If I’m stuck for how to start an utterance I often turn to the Oxford English Dictionary and start from a definition, which often puts me on less sure footing than when I started, but productively so, because we in the humanities like nuanced, complex definitions and are fully willing to let them shift and evolve as we encounter and construct new information. In the world of computer sciences, this is not at all the case. Definitions are agreed upon and clear. In the world of coding, I learned, we can make anything equal anything, so long as what was presented and what was equalled makes sense in the language of the code. What gets outputted might not make any sense — though I was thoroughly amused by the Python tutorials’ references to Monty Python — but it makes something (provided all the quotations, capital letters, and other marks are performed in the right syntax) in that the program can be saved and executed.

Trying to learn Python reminded me of learning the appropriate accents and diacritical marks when I was learning ancient Greek last year. I understood the concept of them, and I even understood the rules for their implementation and why they needed to show up in a particular syllable or why one mark would change into another (in Attic Greek accents will change in different conjugations of a word, depending on the length of the vowel sound and the number of syllables, among other variables). Similarly, I feel I have a base-line literacy when it comes to reading code (at least simple code). I can fairly quickly get a sense about what operation is doing what, and have a sense of why the syntax is in what order. When it came to executing those accent marks though, just like in executing lines of code in Python, I produced all kinds of errors. I’d read the instructions, understand the function of the variable and the rule, and would then have trouble getting it exact enough. Part of this is my own writerly style — things I would naturally want to capitalize in the sentence-level are not capitalized (like print), or some flourish I’d want to write into whatever text I’d produce wouldn’t work because symbols I’d use are (like parentheticals, which I obviously like and use a lot of).

What am I trying to say here — possibly that if as Mateas and others have emphasized that programming is an expressive medium, then I like that idea conceptually but at what point of comfort with programming do I get to express beyond execution? It feels like with other forms of writing, expression can happen immediately. With coding, I’m not so sure. And I’m not necessarily speaking from the expressivists paradigm necessarily, this is not about my autonomous “voice” emerging through the code, it’s about (perhaps) a version of machine-woman symbiosis I just haven’t reached yet.