A Deterministic ppg256

Last night I premiered ppg256-6 in Bergen, Norway:

perl -le '@d=split/ /,"eros won to tree for fire sex sever ate nice tin elfin wealth";@t=split//,"_bhlmnpstw";{$_=localtime;/(..):(.)(.):(.)(.)/;print"\n$t[$3]".($4%2)."ck $t[$4]".($3%2)."ck\n"if!$5;print"\\"x$5." $d[$1%12] $d[$2] $d[$3] $d[$4] $d[$5]";sleep 1;redo}'

This is the latest in my series of 256-character poetry generators written in Perl. An unusual feature of this one is that it is deterministic: If run at the same time, it will produce the same output. Those who run Windows should check the ppg256 page for a .pl file that will run on that OS, on ActivePerl.

Finally, Your 50 Character Reward!

After I presented poetry generators ppg256-1 through ppg256-5 at Banff in February, I shouted out, more or less spontaneously, “50 character reward to whoever gives us the best explanation of what ppg256 is!” Why did I say that? Childhood trauma, possibly, but the more immediate reason, as I mentioned earlier, is that the last of these, ppg256-5, is based on a section of Tristan Tzara’s February 1921 Dada Manifesto, one which ends with the phrase “50 francs reward to the person who finds the best way to explain DADA to us.”

I got some great answers, including “It does a lot with a little” (Chris Funkhouser) and “ppg combines atoms of language” (John Cayley). But at this point I’ll skip right to the one from Travis Kirton, who did the following without having any previous experience programming in Perl:

perl -le '@a=split/,/,"illmn,imgn,ltr,mut,pxl,popl,strlz,pnctu,typfc,poetc,glmr,idl,ion,cptl,cpsl,cvl,atom,pltc,txtul,erotc,rvl";sub f{pop if rand>.5}sub w{$a[rand@a]}{print f("de").f("over").w."izes ".w."ation".f("s")."\n".(" "x45)."IS WHAT ppg DOES!";sleep 5;redo}'

The program is a modification of ppg256-5, one that answers the questions that ppg256-5 generates. That’s not only clever; it showcases the expressive power of small programs and the many, if not arbitrary, uses to which a language generator can be put. This certainly earns the reward. Travis, here’s an base64-encoded version of a 32-byte DOS intro, matisse, by orbitaldecay. When you run it after decoding it with a base64 decoder, it should look like this. The base64-encoded string, you will notice, is exactly 50 characters in length:

sBPNEMUPHgeLFwmXQAEJVwFL4vSsQKq5ZQDkYEh16cM=

Okay, I lied. It’s only 44 characters long. Please accept base64 as the remaining part of the prize.

Now, I think Mark Markino’s explanation of ppg256, which I wrote about yesterday, is also great and will suffice. It’s a wide-ranging and deep study of the series of generators, similar programs I’ve discussed, and some relevant contexts of techneculture. I can’t really decide which of these explanations is best, as they both work excellently for what they are. So I am going to offer Mark Marino a 50-character generator, too. Mark, here is an ASCII encoding of a set of tools that, used properly, will allow you to draw any image:

())\_\_\_RED\_\_\_))\_> ())\_\_GREEN\_\_))\_> ())\_\_\_BLUE\_\_))\_>

Enjoy!

Code is Beauty, Beauty Code

Beautiful CodeIn recent years, I’ve written a series of 1k (that is, exactly 1024 character) reviews on here. This ruse has helped me compose succinct (and possibly useful) notes about many things that I wouldn’t have otherwise written about. But some things that are worth reviewing, such as a documentary about interactive fiction, are really better treated in a bit more depth. Given my interest in the aesthetics of code, and in code that produces aesthetic output, a book entitled Beautiful Code: Leading Programmers Explain How They Think is certainly one of those things.

Beautiful Code is an edited collection of 33 articles by a well-known publisher of technical books. The articles deal with how programmers solved a variety of problems, some of them very general computational problems, others quite specific to particular systems and applications. Several of the authors discuss their own code. The book is part of the Theory in Practice series with Beautiful Data, Beautiful Architecture, and Beautiful Security.

Beautiful Code: Leading Programmers Explain How They Think. Edited By Andy Oram & Greg Wilson. O’Reilly Media, 2007.

Beautiful Code is a success in several ways. It widens the conversation about code and the innovative development of it beyond particular programming languages, which have often been silos for such discussion has taken place in the past. At least, book-length discussion of programming – in textbooks, in introductory and reference books, and in “tips and tricks” books – has often been language-specific. While encompassing many systems and code in many languages, the book doesn’t take the position that the programming language can be abstracted away, that knowing about data structures, algorithms and an arbitrary programming language allows on to say all that can be said about how to program.

The first article is a particularly excellent one. In it, Brian Kernighan discusses 30 lines of regular expression matching C code which Rob Pike wrote as an example in an hour or two. This concise article deals with how to solve the core of the regular expression problem elegantly and correctly, but it also touches on many other important aspects of code and programming. By suggesting a series of modifications, Kernighan shows that code is an element of future programs rather than simply a fixed solution. Kernighan mentions how the code takes advantage of C pointers and suggests converting it to Java to see how the result would be slower and would require a lengthier program. If you can only read one essay in Beautiful Code, be glad that the editors have placed this one in the front, allowing you to retrieve it in a constant-time operation.

I was also interested in how several of the essays dealt with the need to consider hardware specifics, something one might expect pure, beautiful code to avoid touching. There’s some hint of this specter in chapter 7, which discusses how Jon Bently’s official, “proven” algorithm for binary search has a bug when it’s implemented on most real systems. When the code finds a midpoint within the array by computing (low + high) / 2, the sum of low and high can, in very extreme cases, exceed the maximum integer value, giving a negative (and obviously wrong) result. Later chapters deal with more productive connections between hardware and code. In chapter 10, Henry S. Warren, Jr. delves into the amazing intricacies involved in efficiently computing the population count or sideways sum: the number of bits in a word, or an array of words, that are 1. The current best way of doing this for an array involves using a special circuit called a carry-save adder. Chapter 14, “How Elegant Code Evolves with Hardware: The Case of Gaussian Elimination,” explores the relationship of leading matrix algorithms to changing hardware architectures.

Several other articles interested me; I suspect that programming language researchers, professional programmers, and others will find that a good number of the selections are worthwhile.

But despite the title and some compelling discussion inside, this is really isn’t a book about “beautiful code.” There is almost nothing in it about beauty or what that concept means when applied to code. “Aesthetics” isn’t in the index. When beauty is mentioned, it seems obligatory and stands for whatever the author of a particular chapter values. This, for instance, by Travis E. Oliphant:

>”Iterators are a beautiful abstraction because they save valuable programmer attention in the implementation of a complicated algorithm.” (p. 318)

Could one say anything similar about paintings? Sunsets? Or even something that has an important functional aspect, like a building? “Frank Ghery’s Stata Center is a beautiful building because the layout of its hallways saves valuable programmer time.” That doesn’t sound quite right, does it? There are more reasonable-sounding, if not very elaborated, statements about code and beauty in the book, but some of those seem to express a very narrow perspective. For instance, Adam Kolawa writes:

>”In sum, I believe that beautiful code must be short, explicit, frugal, and written with consideration for reality.” (p. 266)

Michael Mateas and I have written about obfuscated code, a topic that isn’t mentioned at all in this book. While obfuscated programs are usually short, they are also the opposite of explicit, gratuitous rather than frugal, and written without any concern for “realities” like re-use, practicality, and legibility. An obfuscated program isn’t good programming practice – that’s part of the point. For reasons that Michael and I have written about, we consider the best examples of obfuscated code to be beautiful, and I suspect we’re not the only ones. They simply display a different kind of beauty, an aesthetic of complexity and extravagance that shows us things about programming and about the language in which the obfuscated code is written – things that technical essays don’t reveal. You may share this aesthetic and be willing to consider obfuscated code beautiful, if, for instance, you saw beauty in the exorbitant Ok Go video “This Too Shall Pass.”

A final disappointment: There are no articles on the creative, artistic use of code, on programming projects that are meant to create beautiful output – no music, poetry, story, or terrain generators, lightsynths, demos, intros, or Processing sketches. Certainly a book about beautiful code, even if it is targeted at the professional programmer, would benefit from investigating a program or two of this sort?

This isn’t to say that valuing conciseness and clarity is a bad idea, or that having a book about utilitarian programming practice, particularly a wide-ranging one with many interesting articles of great technical depth, is a problem. It just means that much work remains to be done on matters of beauty and code. Perhaps we’ll soon see a book that brings together the diversity and depth of technical discussion that’s displayed here with consideration of the nature of beauty, of what it means for code to be beautiful, and of how the workings, conception, code expression, and wider contexts of a program are all involved in its beauty.

New Journal Primes You for ppg256

Emerging Langauge Practices is a new journal based at SUNY Buffalo (poetic hotbed and host of the next E-Poetry) and founded by Loss Pequeño Glazier, Sarah JM Kolberg, and A. J. Patrick Liszkiewicz. Issue one is a real accomplishment.

There are eye-catching creative projects by mIEKAL aND & Liaizon Wakest and by Lawrence Upton and John Levack Drever. There are also pieces by Young-Hae Chang Heavy Industries and Molleindustria. (We can only hope for further industrialization of this sort and more of these compelling productions in future issues.) The issue also includes a piece by Abraham Parangi, Giselle Beiguelman’s mobile tagging, Sandy Baldwin’s plaintive piece “** PLEASE REPLY MY BELOVED **,” and Jorge Luis Antonio’s wide-ranging article on digital poetry.

The item that particularly caught my eye, though, was this article by Mark Marino: “The ppg256 Perl Primer: The Poetry of Techneculture.” Marino is an officer of the Electronic Literature Organization with me and a current collaborator of mine, although he completed this article before joining me on our current project. The discussion he developed for the first issue of ELP is really in-depth. Marino not only considers the workings and connotations of my ppg256 series of poetry generators, and considers related code and literary traditions from Perl Golf to the Oulipo – he also considers other programs that interest me and that I’ve discussed publicly in various contexts, sometimes with collaborators. And, he connects the coding traditions relevant to ppg256 to technical practices in boy culture and (via needlework) girl culture.

In one section near the beginning of the article, Mark relates a line of BASIC that I posted on his Critical Code Studies forum and notes (partly in jest, I think) the following:

>I cannot include the full discussion here (over 5000 words) because as Montfort told me over the phone (in jest, I think), he is planning a book-length anthology of readings about the program.

Well, that’s more or less the project Mark and I, along with several others, are now embarked upon. However, we’re writing this book in a single voice rather than collecting articles about the program. More on that before too long; for now, go and enjoy the new Emerging Language Practices.

Get Lamp and Watch

Get Lamp DVD package coverYou may have noticed a slew of posts on the Get Lamp blog, Taking Inventory, or seen the writeups on Boing Boing, PC Gamer, CNET, or other sites. But I’ll say it here too: Jason Scott’s documentary about text adventures, years in the making, is completed, has been pressed and assembled, and is now for sale and shipping. The movie is Get Lamp, and there is a trailer for it online.

Tipped off by my book Twisty Little Passages: An Approach to Interactive Fiction, Jason Scott got in touch with me way back in 2005, before he had started filming interviews for Get Lamp. He came to Philadelphia, where I was working on my Ph.D. at Penn. I ended up doing one of several interviews with him there and bringing him to Autostart, a digital literature festival I helped organize at the Kelly Writers House, where he interviewed a few of the participants – just a handful of the many dozens of interviews Scott did for the documentary. I’ve gotten to see the documentary develop. I listened to audio files of the interviews, discussed the project on ifMUD, and got to see screenings of early versions with audiences at the Penny Arcade Expo East and @party.

Get Lamp is an essential film for the interactive fiction enthusiast – as I think more or less all of us know already. It’s also going to be an important film for students of electronic literature or computing history. There are some good short YouTube videos explaining interactive fiction, such as Exploring Interactive Fiction, which I did with Talieh Rohani, and Jason McIntosh’s The Gameshelf #8: Modern Interactive Fiction. These are great for people whose interest has been piqued already and who want to know a bit more about IF history and how to play. But it’s really difficult to get contemporary, non-IF playing students to understand why they should give interactive fiction a chance. Those who put a few short games on a syllabus often return to classrooms of perplexed or disgruntled people who have made no progress. Screening at least the “non-interactive” cut of Get Lamp will be time well spent. It will provide ideas for discussion and will give students permission to appreciate interactive fiction in several new ways, allowing them to better engage with assigned games.

It’s people and their stories that are always the focus of a documentary, and that’s certainly the case with Get Lamp, which assembles quips, and the occasional longer argument or rant, from players and authors of different eras. The statements from people in the film give a great sense of the many ways in which interactive fiction was and is important. This is something you don’t get in Twisty Little Passages, because my method wasn’t to interview people about their experiences; I focused more on the printed and digital record, on describing how interactive fiction works, and on scholarly questions about the status and history of the form, for instance, as it relates to the literary riddle. While people are central to the documentary, Scott certainly doesn’t shy away from archival materials such as printouts, maps, and notes or from original early packages in the documentary, though. He uses those worth-a-thousand-words pictures to give a sense of the contexts in which interactive fiction has been played from the early days of Adventure through today. Which I guess means, as everyone’s favorite retail site says, “Buy these items together!” (Actually, though, you should go to the Get Lamp order page to buy the documentary.)

Scott has done a great deal to provide coverage of today’s “modern era” of interactive fiction development while also covering its origins in Adventure, the ties that game has to caving, and the commercial heyday from Adventure International through Infocom. The history of the IF Comp is explained by current organizer Stephen Granade and others, and the emergence of short-form IF (and its relationship to the comp) is discussed as well. But the documentary’s perspective on interactive fiction clearly gazes longingly over the “golden age” of commercial IF, when Infocom was king. There’s the sense – which several people share – that interactive fiction has managed to continue in some ways from that time, which was its finest hour.

That’s not the perspective some contemporary IF authors have, though. For some, Infocom is a happy but dim memory rather than the holy city of Byzantium. Others never even played an Infocom game before playing modern IF and writing their own IF. And of course, games are not just shorter now; they are written in a wider variety of styles on a wider variety of topics. It won’t be tough for enthusiasts to find other favorite aspects of IF which didn’t manage to fit into this full and rich documentary: the relationship to MUDs or the graphical adventure, commercial games in English outside the US, or global communities working on IF in recent years. Which is just to note that while Get Lamp relates an important and untold story, it’s not the _only_ story of interactive fiction. It’s the kind of movie that leaves me listening to my fellow IF authors and aficionados and being constantly surprised about how much I share certain people’s perspectives and how different, at other times, my view of IF is. That’s not just informative; it’s also thought-provoking.

Yes, despite the breadth and unusual textures of the topic, the film goes beyond being a great introduction to IF and the people who play and write it. There are many surprising discussions outside the main line of IF history. The academic study of IF is discussed by Mary Ann Buckles, whose 1985 dissertation on Adventure is the first study of IF and probably the first long example of work in game studies. John Romero explains the debt that computer games in general owe to text adventures. Robert Pinsky, who has served as poet laureate in addition to writing the IF Mindwheel, discusses puzzles and the pleasures of literature. Other less-than-usual suspects chime in, including fellow academics and collaborators of mine Jeremy Douglass, Ian Bogost, and Stuart Moulthrop.

One of my favorite points in the movie is when Brian Moriarty says empathetically of the Infocom catalog, “It was for literate people – it was for people who like to read!” Get Lamp is also for people who like to read, explore, and see from different perspectives. It’s not only for those who have already discovered interactive fiction, but it will delight most those who are enthusiastic about computing and what the computer can do with storytelling, language, and the modeling of words.

Jason Scott is now preparing for a “Jet Lamp” tour in September, in which he’ll show the film around the country. Perhaps you’ll get to catch it at a theater near you.

One-Line C64 BASIC Music

Local sound artist/electronic musician Keith Fullerton Whitman released an extraordinary piece on the b-side of his November 2009 cassette hallicrafters, inc. The piece is called 10 poke 54272+int(rnd(1) *25),int(rnd(1) *256) : goto 10 and is 18 minutes of sound produced by a Commodore 64 emulator running the BASIC program that is the title of the piece.

The memory locations beginning at 54272 are mapped on the Commodore 64 to the registers of the SID (Sound Interface Device). By POKEing random values into them, the SID, although it is a musical chip, is stimulated to produce sounds in what probably seems like a non-musical way: based on the effect of register settings and the sequence produced by the system’s random number generator, a polynomial counter.

I’m listening to the piece running on a hardware C64 now, which is soothing, although it seems like it shouldn’t be. Looking at the code, I note that the program

10 poke 54272+rnd(1) *25,rnd(1) *256 : goto 10

will put the same values into the same memory locations (and therefore SID registers) in the same order. The INT function is unnecessary because all arithmetic in C64 BASIC is done in floating point and then cast to integer whenever necessary. It’s possible that removing these functions will cause the piece to speed up, however, and I suspect it will, even though a BASIC interpreter could skip the unnecessary INT calls to begin with. There would be various ways of determining this, but the one I’d like to try involves getting two C64s, each with one version of the program, and seeing if they go out of phase.

By the way, I say that these two programs will put the same values in the same order because RND(1) returns a deterministic sequence. Any time either of these programs is invoked before other calls to RND are made, they will produce the same sequence. Using RND(0) would seed the random number generator on the jiffy clock, so would do different things depending upon how long the computer had been on before startup.

Thanks to sound artist and digital media scholar Kevin Driscoll, a.k.a. Lone Wolf, for letting me know about this.

Update: Hilariously, I overlooked that Whitman is not the author of this program – he credits Noah Vawter, a.k.a. Shifty, who is currently collaborating with me on a project about a one-line Commodore 64 BASIC program. I guess I was too distracted by that picture of an iPhone running a C64 emulator.

Computational Creativity: ICCC-11 CFP

A great event will be taking place in Mexico City at the end of April, one that is sure to help us connect computing and creativity in new ways. I’m helping to organize ICCC-11 and am planning to be there. I hope some of you will submit to this conference, and that I’ll see some of you there. -Nick

Update, October 2011:The 3rd International Conference on Computational Creativity will be May 30 – June 1, 2012 in Dublin, Ireland; The deadline is January 16, 2012. ICCC-11 was great, and I and others are looking forward to ICCC-12! Hope to see you there. -Nick

#### 2nd International Conference on Computational Creativity
##### April 27-29, 2011
Mexico City, Mexico
http://iccc11.cua.uam.mx

Original contributions are solicited in all areas related to Computational Creativity, including but not limited to:

1. computational paradigms for understanding creativity, including heuristic search, analogical and meta-level reasoning, and re-representation;
2. metrics, frameworks and formalizations for the evaluation of creativity in computational systems, note: quasi-formal approaches that, for example, argue for recognition without definition or that define the absence of creativity may have interesting implications for computational creativity);
3. perspectives on computational creativity, including philosophy, models of cognition and human behavior, and intelligent systems;
4. development and assessment of computational creativity-support tools;
5. creativity-oriented computing in learning, teaching, and other aspects of education;
6. innovation, improvisation and related pursuits investigating the production of novel experiences and artifacts within a computational framework;
7. computational accounts of factors that enhance creativity, including emotion, surprise, unexpectedness), conflict, diversity, motivation, knowledge, intuition, reward structures, and technologies, e.g. modeling, simulation, human-in-the-loop, human/machine collaboration, etc.);
8. computational treatment of social aspects of creativity, including the relationship between individual and social creativity, diffusion of ideas, collaboration and creativity, formation of creative teams, and creativity in social settings, e.g. modeling, simulation, human-in-the-loop, human/machine collaboration, etc.);
9. specific applications, with a computational component) to music, language, narrative, poetry, the arts, architecture, entertainment, mathematical and scientific discovery, programming and/or design;
10. detailed system descriptions of creative systems, including engineering difficulties faced, example sessions and artifacts produced, and applications of the system;
11. domain-specific vs. generalized creativity — does the domain of study affect, the perception of) creativity? Are there general, computational) creative principles that can be applied across domains?

#### PAPERS

We invite papers that make a scientific contribution to the field of computational creativity and report work that involves computation, e.g., fully autonomous systems, modeling, support for human creativity, simulation, human/machine collaboration, etc.).

We welcome studies of human creativity that in some way propose a computational model for that creativity.

When papers report on creative computer systems, we particularly encourage them to discuss systems having general or at least multiple sorts of results, to detail the methods used to design and develop the system, or to include useful related theoretical discussion.

We invite papers that go beyond simply documenting interesting systems to describe advances in cognitive science, assessment methods, design methods, or other research areas.

#### DEMOS/ARTS SHOW AND TELL

We invite proposals for demonstrations of computational systems exhibiting behavior that would be deemed creative in humans and for the exhibition of artifacts created using computational means, either primarily or as support for a human creator).

More information will soon be available at: http://iccc11.cua.uam.mx

Or, send email to: iccc11@correo.cua.uam.mx

#### IMPORTANT DATES

December 13, 2010 — Submission deadline

February 14, 2011 — Authors’ Notification

March 14, 2011 — Deadline for final camera-ready copies

April 27-29, 2011 — ICCC in Mexico City

#### CONFERENCE ORGANIZATION

General Chair:
Graeme Ritchie, University of Aberdeen

Program Chair:
Dan Ventura, Brigham Young University

Local Chair:
Rafael Pérez y Pérez, Universidad Autónoma Metropolitana – Cuajimalpa

Publicity Chair:
Nick Montfort, Massachusetts Institute of Technology

Senior Program Committee:

  • Pablo Gervás, Universidad Complutense de Madrid
  • Fox Harrell, Massachusetts Institute of Technology
  • Mary Lou Maher, University of Sydney
  • Alison Pease, University of Edinburgh
  • Geraint Wiggins, Goldsmiths, University of London

Program Committee:

  • John Barnden, University of Birmingham
  • David Brown, Worcester Polytechnic Institute
  • Win Burleson, Arizona State University
  • F. Amílcar Cardoso, Universidade de Coimbra
  • John Gero, George Mason University
  • Ashok Goel, Georgia Institute of Technology
  • Paulo Gomes, Universidade de Coimbra
  • Kaz Grace, University of Sydney
  • Kyle Jennings, University of California, Berkeley
  • Robert Keller, Harvey Mudd College
  • Brian Magerko, Georgia Institute of Technology
  • Ramon López de Mántaras, IIIA-CSIC
  • Ruli Manurung, University of Indonesia
  • David C. Moffat, Glasgow Caledonian University
  • Diarmuid O’Donoghue, National University of Ireland
  • Sarah Rauchas, Goldsmiths, University of London
  • Mark Riedl, Georgia Institute of Technology
  • Juan Romero, Universidade da Coruña
  • Rob Saunders, University of Sydney
  • Ricardo Sosa, Tecnologico de Monterrey
  • Carlo Strapparava, Istituto per la Ricerca Scientifica e Tecnologica

Creating Adventure in Style and The Marble Index in Curveship

##### The blog edition of my presentation at the Electronic Literature Organization’s ELO_AI Conference, Brown University, 5 June 2010

The process of writing and programming the first two full-scale interactive fiction pieces in the new system I have been developing, Curveship, has been a part of my poetic practice that I have found interesting and has also been a useful activity from several perspectives. Here I focus on the project _Adventure in Style_. I will also mention _The Marble Index_, a project that contrasts with _Adventure in Style_ in an important way. These two pieces, still in progress, are initial explorations of the potential of Curveship and of the automation of narrative variation. My hope has been that these two games will serve as provocative interactive experiences, whether or not those who interact with them are interested in Curveship as a research project or as a development system. Of course, it will be very useful if they also serve as demonstrations of how Curveship works. I have, additionally, used these two projects to help me determine what additional development is critical before I release Curveship.

While Curveship has functioned as a research system for several years and has been previously discussed from the standpoints of computer science, artificial intelligence, and narrative theory, this is my first attempt to discuss the specific pieces of interactive fiction that were conceived as aesthetic projects, rather than primarily for research or demonstration purposes.

#### Curveship

The system used to implement these pieces, Curveship, is an interactive fiction development system that provides a computational model of a physical world, as do existing state-of-the-art systems such as Inform and TADS. Curveship does something significant that other systems do not: It allows author/programmers to write programs that manipulate the telling of the story (the way actions are represented and items are described) as easily as the state of this simulated world can now be changed. It has been straightforward to simulate a character and to have that character move around and change the state of the world. In addition to this, Curveship provides for control over the _narrator_, who can speak as if present at the events or as if looking back on them; who can tell events out of order, creating flashbacks or narrating what happens by category; and who can focalize any character to relate the story from the perspective of that character’s knowledge and perceptions.

Curveship is a Python framework which will run on any computer that runs Python; I intend to release it under a free software license when it the core aspects of it are complete, well-tested, and well-documented. Rather than repeat what is already online about the system, I’ll just mention here that information about Curveship is available in several papers and in my 2007 dissertation. The best place to begin reading about the system is [my blog, _Post Position_](http://nickm.com/post/tag/curveship/), where papers and my dissertation are linked. My blog posts use the same (simplified) terminology as does the code; these terms (such as “spin” to refer to the specification for narrating) are the current, official ones. Some of my earlier publications, although they represent many aspects of Curveship well, use out-of-date terms.

#### _The Marble Index_

_The Marble Index_ simulates the experiences of a woman who, strangely disjointed in time and reality, finds herself visiting ordinary moments in the late twentieth century; the narration accentuates this character’s disorientation and contributes to the literary effect of incidents. So far, only a few sketches of parts of _The Marble Index_ have been done. In _The Marble Index_, the narrative style is controlled by the interactive fiction program. I am not very far along on this project, but I mention it because I anticipate that, just as the interactive fiction programs takes care of simulating the world in current IF, the program will usually take care of modifying the narrative style in a less direct way. _The Marble Index_ will probably be more representative of how the narrating will be controlled in a “typical” Curveship piece.

#### _Adventure in Style_

_Adventure in Style_ is in part a port of the first interactive fiction, the 1976 _Adventure_ by Will Crowther and Don Woods – one which adds parametric variations in style that are inspired by Raymond Queneau’s _Exercises in Style_ (_Exercises de style_, 1947). For several years, I have been beginning my presentations about Curveship by showing that the goal of the project is to combine _Adventure_ and _Exercises in Style_, because the two pieces show what is essential and compelling about interactive fiction (simulating a storyworld with a text interface) and about narrative variation. Now, in working on a creative project which is supposed to be effective as a stand-alone piece, not only as a demo, I am trying to combine these two much more literally.

In _Adventure in Style_, the player can rather directly control the narrative style by commanding the player character to manipulate an in-game object. The critical object here is the lamp, which the adventurer almost always needs to be holding in the cave. A special case, in which the player chooses to use the standard style throughout an entire traversal, gives the player an experience much like that of running the original _Adventure_ program. The fictional work of _Adventure in Style_ is almost complete, with the cave laid out as in _Adventure_ and many of the treasures and other objects implemented. Although the fiction file has not been fully tested, the map of and most of the puzzles in _Adventure_ are in place. Several of the possible variations in style, but not all the ones that are planned, have been implemented as well.

Several of my interests flow together, and then underground, in _Adventure in Style_. It is a port, and during my investigation of the Atari VCS (Atari 2600) with Ian Bogost as we worked on _Racing the Beam_, I found that ports are fascinating because they involve thinking about the essential aspects of a game and how they can be expressed in different ways across different platforms. When played in the standard narrative mode, one can see that _Adventure in Style_, in reimplementing a previous game, aspires to the unoriginality of Kenneth Goldsmith’s practice of uncreative writing, in which a writer simply transcribes or retypes text, such as a year’s worth of radio weather reports or a particular issue of _The New York Times_. Since narrative variation, the only aspect of the project that doesn’t come from _Adventure_, comes from _Exercises in Style_, _Adventure in Style_ is thoroughly uncreative: neither the original game nor the concept of variation sprang from my fictive forehead. Nevertheless, or perhaps because I have avoided trying to make any real contribution of my own, I find that these two great tastes taste great together. They serve as a way to understand the computer’s power to control the telling of a story and to model an underlying story world.

#### Grue Street

I took _Adventure in Style_ to the first meeting of Grue Street, an interactive fiction writers’ group that I started in Cambridge, Massachusetts as an offshoot of the local IF organization, The People’s Republic of Interactive Fiction. (In the tradition of Infocom’s _The New Zork Times_, we named the group to riff on a local writing center, “Grub Street.” Hopefully this organization won’t follow the lead of the Grey Lady and threaten us with a lawsuit.) Grue Street got off to a good start with six games and seven authors – one game was a collaboration. We required each attendee to bring something playable to the meeting, a “situation” of some sort:

> “Situation” can mean something like a puzzle, task, or conversation, which may take place in one room (or scene) or in several. The term is meant to be pretty open; it’s mainly to encourage authors to have more than just an empty setting (with nothing to do in it) or a lone character or collection of objects (with no reason to interact). You don’t need to have your whole game completed or even sketched out to participate.

The writers interacted with each piece as a group. On the one hand, this left each of us with only one transcript of play to study, but, on the other, it gave authors the opportunity to hear players thinking out loud and talking with each other.

I didn’t come away from the meeting with any ideas for major revisions to _Adventure in Style_, but the group’s reaction did help me think about frame the game, creating a useful welcome message, and choosing a good variation to introduce initially. It also made me realize that it will be hard for some people to see the project as anything more than a demo of Curveship.

#### Three Goals

My work on Curveship has been directed toward three major goals:

1. To advance and support research in natural language generation, narratology, computational creativity, and related fields.
2. To create a functional IF development system that allows authors to create games for players.
3. To enable new, compelling literary and aesthetic experiences.

“Shimmer,” advertised during the first season of _Saturday Night Live_, was a substance designed to be both a floor wax and a dessert topping. To update this for the 21st century, we might image a substance that is a floor wax, a dessert topping, and a hand sanitizer. While the three goals of Curveship do work together in certain ways, in other ways they make the research, development, and creative project seem a bit like “Shimmer Plus.”

An IF development system needs a reliable way for players to download games and probably for them to play games online, and, among other things, it needs a start-of-the-art parser. These are useful for goal 3 but unnecessary for goal 1. Generally, goal 1 and goal 3 involve pushing the envelope in some ways that are similar and some ways that are different, while goal 2 requires stability, documentation, and ease of use.

There are projects that have taken on two major and distinct goals at once. _Façade_ by Michael Mateas and Andrew Stern was an attempt to create a highly distributable, playable, and enjoyable experience that also advanced the state of the art of interactive drama. It was not itself a platform or development system, however. Graham Nelson’s co-development of Inform and _Curses_ involved creating a literary work and the now-dominant IF development system, but Inform (which has since been developed in very intriguing new directions) was not initially focused on expanding the possibilities of IF. Daniel Howe’s RiTa and Ben Fry and Casey Reas’s Processing have been developed first and foremost as general platforms, but have contributed along other lines. Nevertheless, projects that strive toward all three of these goals are rare.

I will be re-opening activity on Curveship this summer and would be glad to hear from people interested in using the system, as this will help me focus my efforts and create a release that works for the community interested in the system’s capabilities.

@party: Weaving thread

I spent this weekend at @party 2010, the first (and hopefully not last) demoparty of this name. The event was in the Town of Harvard, Massachusetts – a bit outside of Boston. I heard four live music performances, saw an early cut of Jason Scott’s almost-finished Get Lamp documentary, and saw and heard grafix, music, and demos (wild and windows) in the Saturday evening compos. There were great tunes, a truly excellent 4k windows demo, an incredible demo running on an Arduino, and much more. Many thanks to the organizer, Metoikos, and everyone who helped her out. And, a big thanks to the demoscene!

Working with two others and using the moniker “nom de nom,” I completed my first demoscene production: thread, a Commodore 64 demo that has fewer than 32 bytes of code. (There are no C64 demos this size or smaller on pouet.net, as far as I can tell.) This demo is a tribute to a BASIC program that generates random mazes, one that exists in one form in the C64 User’s Guide but has also circulated as a one-liner. Here’s a version of the program:

10 PRINT CHR$(205.5+RND(1)); : GOTO 10

I developed thread working in person first with Le Colonial of Atlanta, a sometime co-author of mine who also writes Atari VCS games. (He’s also known as Ian Bogost.) At the party itself, I was fortunate to encounter C64 expert rv6502 of Montréal, who joined me and did the heavy lifting in the second phase of this project.

After working one evening with Le Colonial in Cambridge, we had a 32 byte program that wasn’t exactly like the original, but did something pretty cool. When I checked it out on my actual C64 right before I left for the party, however, it didn’t work. The SID was initialized differently in the emulators I’d used than it was on the box itself – as it happened – and there was something odd happening with my video display as well.

I brought my C64 to the event rather half-heartedly, without any way of getting programs onto it other than typing them in and without a display. Alas, I wasn’t going to get away from the program that easily: Dr. Claw brought me a monitor to use and NO CARRIER loaned me a flash cart – and, later, a physical copy of the Commodore 64 Programmer’s Guide. rv6502 and I sat down to work further on the program. It turned out my C64’s video was different that of the emulators I used, but also different from Ferris’s actual C64 (which matched the behavior of the emulators I tried). So it wasn’t just an emulator failing to match the metal; the two different C64s apparently have different KERNAL code in ROM. Dumping my machine’s ROM and used that with my emulator would have solved that part of the mismatch.

I won’t try to go into all the details of developing this demo, but there were two particularly great things about the process at a high level. First, I got to collaborate with and learn from two others at different points. Second, I got to learn a lot more about the C64, including many things I wouldn’t have run up against if I hadn’t been working on something like this. I’m not talking about small differences between emulation and the hardware, which were a minor part of this experience, in the end. I mean finding excellent facilities of the 6502 and the C64 to work around those which weren’t doing what we wanted.

We’ve released thread in three versions: The canonical one, which has 31 bytes of code but is in a 33-byte PRG file, because the beginning memory location is stored in the first two bytes of PRG files. If this bothers you, there is a 28-byte version which fits into a 30-byte PRG file and has all the same colors, but displayed in a way that we think is not as pretty. We also include a simple, straightforward reimplementation of the BASIC program above: A 20-byte program in a 22-byte PRG file. I’d love to get this uploaded to pouet.net at some point, but I don’t know how. For now, here’s a zipfile with source and PRGs.

thread got 4th place in the Oldschool category at @party. After you load a PRG file in your emulator (or on your C64), you can run it by typing “SYS 4096”.

Finally, these are the 31 bytes of thread:

A9 80 8D 0F D4 8D 12 D4 A8 B1 F9 8D 86 02 AD 1B D4 29 01 69 6D 20 D2 FF E8 D0 ED E6 F9 50 E9


The First Oration against the Parser

Emily Short wrote an intriguing post about the parser in IF – actually, somewhat against the parser in IF. She explores alternatives to what she calls the “command line” in IF (not entirely inaccurate, but not the connection I’d most want to make) and ends up finding it to be more or less the worst of all systems except all the others, like democracy. The post has already garnered about 50 comments. In it, Short writes:

We have a two-part accessibility problem. One part is the interpreter: people don’t want to download separate files and don’t want to have to figure out file formats … The other problem is the parser.

I see a few problems with this. First off, let’s not stop at two. The world model that IF presents (with “rooms,” containment, light sources, and so on) is hardly accessible or immediately obvious. I think it works fairly well and creates a good abstraction of world that is suitable for text-based interaction. I think the world model of IF is a strength of the form, a success. But you still have to learn it. Figuring out the layout of an IF world is perhaps easier for new players in 2010 than it was in 1976, but there are certainly challenges to accessibility today in this aspect of IF.

The discussion in this post of the natural-language interface of IF and its supposed failings is what really seems to me to fall short:

Fundamentally, however, we’ve got a bigger problem, which is that the command prompt is a lie. It tells the player “type something, and I’ll understand you.” Which it won’t.

All interfaces are lies, in this case. If I click on my desktop, or on a blank area of the menu bar, it does nothing – or, you could say, it “doesn’t understand me.” If Mario is up against a wall, pushing the joystick (or d-pad) in the direction of the wall does nothing. There are plenty of ways to get almost any computer interface to not give you results, if you don’t learn how it works. You always have to learn something about how to use the interface to be able to control the computer program that uses it.

The parser, which asks “What do you (the detective) want to do now?” is making an offer: Tell me a simple action, usually a physical one such as PICK UP AX, and I’ll instruct the player character to do that. Yes, we have abbreviated way to indicate these actions: “east” or even “e” to mean “walk east,” “inventory” to mean “look at what I’m holding,” and so on. But I see the overall framework of interaction as being clear enough for players to learn, even if there are some issues for newcomers to IF.

I find Aaron Reed’s work hypertextualizing IF and allowing for other sorts of inputs to be intriguing, but I’m not compelled to go in this direction myself. I’m pleased with the textual exchange between player and computer and the basic framework in which the player is invited, consistently, to give a character an action to carry out. In the service of making things accessible, efforts to extend the parser to understand things such as “herring” are moves away from consistency. They may work in some ways, but they make this sacrifice.

Similarly, I disagree that it would be a good idea to have (as Short proposes) “a system where the player could select a noun, see what he could do with it, and select one of those options.” I actually wouldn’t particularly want this, any more than I’d want to be able to say “TURN LEFT!” to my car and have that override the steering wheel. It makes sense for a programmer to be able to determine an object’s methods, but the experience of IF for me is not mainly about programming; instead, it’s about directing a character through a world, often one that is strange. Using langauge, and specifically, a reasonably negotiated subset of a natural language like English, seems suitable for this.

I have to note in closing something that I find a bit amusing: As Inform 7 is taking a programming language for interactive fiction in a radically more natural-language direction, Short is arguing for an IF interface that is less like natural language.

Short has provided a prototype as part of her discussion, which I admire and wish I could do. Maybe after I finish Curveship…

ELO_AI at Brown Wraps Up

The Electronic Literature Organization‘s conference at Brown University has new concluded – the workshops, performances, screenings, exhibits, and sessions all went very well, as did the coffee breaks and other times for informal conversation. Many thanks to the organizer of ELO_AI (Archive & Innovate), John Cayley!

The conference was a celebration of and for Robert Coover, co-founder of the Electronic Literature Organization and major American novelist, whose teaching and promotion of electronic literature has been essential to the field. Robert Coover was toasted and at least lightly roasted, heard papers presented on his work, and did a reading of the “recently renovated Hypertext Hotel” – a famous early project by students which did indeed turn out to have some recent renovations.

ELO_AI began on Thursday with an array of workshops by Damon Loren Baker, John Cayley, Jeremy Douglass, Daniel Howe, and Deena Larsen. Deena Larsen was later part of a great roundtable on archiving with Will Hansen, Marjorie Luesebrink, and Stephanie Strickland; the group discussed Duke University’s work with Stephanie Strickland’s papers (and digital works), the Deena Larsen Collection at the University of Maryland, and the efforts that the ELO made in the Preservation, Archiving, and Dissemination project. On the first day of the conference, Mark Marino organized a great panel with four undergraduate presenters. And, there was an opening reception at the Westminster Street gallery where an excellent show of digital literary work has been put together. While there was an array of work (in the screenings, performances, gallery, and sessions) from people who were presenting at an ELO conference for the first time, I was also glad to see many of the people who were instrumental in creating and publishing literary work on the computer more than a decade ago.

Without trying to enumerate every session of the conference, I’ll mention the Sunday 10am plenary to try to get across how wide-ranging the presentations and presenters were. In this session, George Landow, author of the famous Hypertext: The Convergence of Contemporary Critical Theory and Technology (1992), told the tragicomical tale of hypertext’s use in education at Brown. Angela Chang and Peggy Chi described two interactive projects for very young readers, projects that used my Curveship system and the Open Mind Common Sense project from Henry Lieberman’s MIT Media Lab group. Lawrence Giffin used the not-very-democratic framework of the salon to consider the important avant-garde site Ubuweb. And finally, Paola Pizzichini and Mauro Carassai looked into the Italian edition of Michael Joyce’s Afternoon and its almost total absence from Italian libraries. Certainly, some sessions were more focused – very focused in the case of the one on William Poundstone’s digital writing work; at least with a theme of process intensity, in the case of the session were I presented my work on Adventure in Style. But we had a genuinely diverse group of presenters, and sessions like this one on Sunday revealed this, while also showing that we do have cross-cutting interests and that we can have valuable conversations.

A special area if interest for me, interactive fiction, was represented by Aaron Reed, who did a reading of his Blue Lacuna in which he deftly showed both interactive sessions and the underlying Inform 7 code while a volunteer interactor spoke commands. Aaron Reed also gave a paper on that large-scale piece, explaining his concept of interface and his work on developing a non-player character who ranged across different spaces without being a simple opponent or companion character. In the same performance session and paper session, I got to see and learn more about Fox Harrell’s Living Liberia Fabric, a piece produced in affiliation with the Truth and Reconciliation Commission (TRC) of Liberia, incorporating video testimony, and employing Fox Harrell’s GRIOT system for poetic conceptual blending.

We welcomed new ELO board members and officers. Joining the ELO board are Fox Harrell, Caroly Guertin, and Jason Nelson. Dene Grigar took office as vice president, and Joe Tabbi completed his term as president, handing that role over to me.

During the sessions, we heard critical perspectives on many particular electronic literature work and some on the ELO itself, which will help us think about the challenges the Organization faces and how we can better serve readers and writers beyond American universities. The ELO has had ten years of growth and learning by now, and while there will be more of each to do, our four main projects are now well enough established that all of them are past 1.0:

  • The Electronic Literature Collection, the second volume of which has been edited and produced by an independent editorial collective and will be published soon.
  • The Electronic Literature Directory, which in its new manifestation offers community-written descriptions as well as metadata.
  • Our conference – this most recent one at Brown was our fourth international gathering.
  • Our site and our online communications, which offer information about the ELO and an introduction to electronic literature.

I’m glad to be starting my service as president of the ELO at a time when the organization has just had a very successful conference and has these other effective projects rolling. Thanks to Joe Tabbi and other past presidents and directors of the Organization for bringing us to this point – and, again, to John Cayley for bringing us all together at Brown.

Once More into the Gorge

J.R. Carpenter has taken apart and reassembled my poetry generator Taroko Gorge. (The first to appropriate and rework that piece, as far as I know, was Scott Rettberg, who created Tokyo Garage.) J.R.’s piece – one might call it a tract of sorts – is simply called Gorge. (Update: J.R. has a post discussing Gorge, too.) See if you can stomach it, and for how long.

Also, check out J.R.’s project Story Generation(s), which involved reworking two of my 1k Python programs and which launched May 8 at PW10 Performance Writing Weekend. The project includes a JavaScript port of “Excerpts from the Chronicles of Pookie & JR.” This is generally not a bad idea; I wrote Taroko Gorge originally in Python (a programming language I prefer for when I’m thinking) and converted it to JavaScript for easy web viewing.

Critical Code Studies Conference at USC

My collaborator Mark Marino is putting on a conference at USC which looks to be a great event. (I don’t pimp conferences on the blog here unless I’m involved in organizing them or planning to attend; I’m certainly submitting to this one.) Note that abstracts are due very soon – June 1.

Announcing a 1-Day conference on Critical Code Studies at the University of Southern California

Critical Code Studies @ USC

July 23, 2010
Hosted by The Center for Transformative Scholarship & The Institute for Multimedia Literacy

Keynote: Wendy Hui Kyong Chun, Brown University

As digital humanitarians continue to turn their attention to the software and hardware that shape culture, the interpretation of source code offers a rich set of symbols and processes for exploration.

Critical Code Studies names the practice of explicating the extra-functional significance of source code. Rather than one specific approach or theories, CCS names a growing set of methodologies that help unpack the symbols that make up software. While still in its initial state, this nascent area of study has been growing rapidly over the course of 2010.

Following the massively successful Critical Code Study Working Group, we will be gathering at USC for a one-day conference to present readings of code. We are currently exploring the innovative publication of conference proceedings through Vectors and others partnerships.

Wendy Hui Kyong Chun, author of Control and Freedom: Power and Paranoia in the Age of Fiber Optics, will present a keynote address. During the Working Group, she presented a powerful chapter from her monograph, Programmed Visions: Software, DNA, Race (forthcoming MIT, 2010).

Please submit a 250-word abstract to markcmarino at gmail dot com by June 1, 2010 (Subject: “CCS @ USC 2010”). Presenters will be notified by June 15.

IF Contests Everywhere

Hello from the People’s Republic of Interactive Fiction.

The TWIF Comp, a contest for interactive fiction with code of 140 characters or less, recently wrapped up. (We’re playing some of the games at the PR-IF meeting today.) Although it certainly had its in-joke aspects, the competition did bear amusing fruit, and it’s only one example of several recent competitions beyond the traditional big annual IF Comp. Given my interest in tiny literary systems, I certainly gave some thought to entering this one. However, I’ve pledged to spend all of my IF-writing time working on or in Curveship, and 140-character programs in the system weren’t at the top of my to-do list.

Before the TWIF Comp, there was the Jay Is Games interactive fiction competition, and after it there is the Second Annual MetaFilter Interactive Fiction Contest, which just started on Saturday. Those who read German will be delighted to know, if they don’t already, that the Grand Prix 2010 has just concluded. There’s also going to be an interactive fiction competition (for 30-minute-playtime games) at the Massachusetts demoparty @party. (Information will be posted on the site soon.) And Introcomp is gearing up: Interested parties should indicate their intention to enter by the end of the month. In case you’re new to online competitions, comps, or “compos” as they are sometimes called, these are not furious masculinist agons; they are mainly excuses for people to complete games and have them played by a bunch of people.

At the very least, you IF-interested parties should take a look at the games being proffered in recent contests – or, see if you want your IF to be part of one of these occasions.

The Garden of Grand Forks: UND Writers Conference

I recently went from presenting at the prestigious and vibrant University of North Dakota Writers Conference to being on a panel at the massive Penny Arcade Expo in Boston.

First things first: The former was “Mind the Gap: Print, New Media, Art,” the 41st UND Writers Conference. Last year at UND the presenters included Charles Baxter and Chuck Klosterman; the year before, Russel Banks, my colleague Junot Díaz, Alice Fulton, and Salman Rushdie.

To provide some perspective, back in 1978 the lineup at this conference was John Ashbery, Amiri Baraka, William Burroughs, Ring Lardner, Tillie Olsen, and Eudora Welty.

This year I heard Art Spiegelman in conversation about his comic and New Yorker cover art, Frank X. Walker on his poems giving voice to the journey of York (who accompanied Lewis and Clark on their expedition as Clark’s slave), Cecelia Condit on her video art, and three of my fellow electronic literature writers, with their diverse approaches: Mark Amerika, Deena Larsen, and Stuart Moulthrop. I had to leave before I could hear slam poet Saul Williams, but I’m grateful for what I was able to experience of the conference. And I’m grateful that I was able to be on two panels, select a reel of music videos for the associated film festival, speak to a computer science class, and present several collaborative and individual projects to a sizable audience in the main room of UND’s student union:

  • Ad Verbum, my interactive fiction piece from 2000, inspired by the constrained writing of the Oulipo. Thanks again to the young interactor who volunteered to try collecting items in and escaping from the Sloppy Salon.
  • 2002: A Palindrome Story, by Nick Montfort and William Gillespie. I showed the Reifier interface and read from the very beginning and end.
  • Implementation by Nick Montfort and Scott Rettberg. I explained the project and read eight texts (stickers, mailing labels) from it.
  • Currency, by Roderick Coover (video) and Nick Montfort (text). I showed “Filip a Guinea: The Elephant and Castle.”
  • Taroko Gorge, the poetry generator I wrote in Taiwan.
  • My ongoing series of tiny perl poetry generators, ppg256.

The people in Grand Forks, ND were polite (I was told I shouldn’t be surprised about this) but also surprisingly receptive. It was certainly a different sort of crowd than I met at Banff, with many people from the community and even driving in from surrounding areas. I think they saw some of the pleasure in writing under constraint, some of the benefits of writing collaboratively, and some of the potential of computation, which I tried to show could be turned to literary ends.

Although I got to converse with Stuart and Deena on and off our panels, I came in too late for one of their readings and had to leave before I could hear the other one. I did get to hear Mark Amerika take us from his early writing in The Kafka Chronicles up through his Web work and recent moving image project, all of which are fresh and impressive. His video work is certainly impelled ahead by the work of Chris Marker, whose Sans Soleil Mark selected for the film festival. I should note that I also loved getting to watch Timecode, Stuart Moulthrop’s selection.

Thanks again to Crystal Alberts for inviting me and for her work on this very successful conference.

When I can manage, I’ll write a bit about the very different but also incredible Penny Arcade Expo East…

We Cured Unix – Now What?

I’m here at LibrePlanet 2010. Although I’m not going to bust out with full-conference liveblogging (that’s so 2005) I do have a quick summary, and a reaction, to today’s opening talk and the ensuing discussion. The presentation was “We’re done cloning Unix, what next?” by John Gilmore, co-founder of the EFF and founder of the “alt” branch of USENET.

My notes from Gilmore’s talk: The GNU plan from the beginning (with Stallman writing Emacs) was to replace proprietary Unix with free software. Now … “We’re sort of like one of those medical charities that has succeeded in wiping polio from the face of the earth.” And it’s not only Unix – CodeWeavers has also pretty much finished reimplementing the user side of Windows, so that Wine (a free software Windows emulator) works more often than not with arbitrary Windows programs. Replacing Windows makes sense as an external goal, but “how many people in our community want to understand the guts of Windows and replicate it?” So, what is our common goal now?

Mentioned in Q&A: ReactOS … We’re not finished with free software beyond the nerdy command line; for instance, video editing; free software for hackers only as opposed to school systems, the business world? … Wine and Samba are very tactical moves to keep the majority market-share players from having control; what about Facebook? … Reverse-engineering tools to understand binary programs … Support the abandoned Windows XP platform for the users trapped there … Communications, content, and services; for an open Facebook, we need open services … free software that uses new paradigms, not the Microsoft model … Having a solid computer gaming framework would be good; the best games make you think and expand your mind … Wine should be like Vaseline, easing the transition from non-free to free; we need a better UI … What about free software in cars?

Although I am part of the FSF, I’m in no way a GNU hacker and my participation in free software isn’t nearly as great as with most people in the room. So I decided, rather than jumping in to the discussion, to offer my comment and my suggestion for a post-Unix project here:

The real thing that the group here has to offer the world is not to follow up a free Unix-like system with a free Windows-like one or with free firmware. It’s probably not even a better user interface or better video-editing software. I suggest that it’s the power to program the computer and to control computation and networking, not just to edit documents and media. Obviously computers *can* be programmed right now, but people like the ones here have a oligopoly on this sort of programming. Whether or not we’re equally skilled in all areas, we’re for the most part comfortable with the idea writing Perl to process text, setting up cron jobs, writing GUI applications, writing servers in Python, and programming games. We don’t think it’s beyond our reach.

That’s not a typical attitude. Maybe it was in 1983, when home computers ran BASIC (gasp – Microsoft BASIC! Ripped off from Dartmouth…) and people who bought these computers and brought them home learned to program them as a matter of course. But it isn’t now. Proprietary software discourages programming by “ordinary people” and encourages office-style and traditional production-style approaches. The people here who hack on GNU aren’t, generally speaking, expert video editors or UI designers, although there are surely of few of each here. The real strength that the group has is in being expert at programming. What they can offer the world, beyond free imitations of existing systems, is a computer that is more free to program, that by design (not just by license) encourages users to work and play powerfully as programmers.

GNU’s first project, Emacs, is not just a text editor; it is also a programmable environment, a major part of its appeal to many programmers. To look to more recent projects, I find Processing a particularly powerful piece of free software that allows students and artists to use visual, computational capabilities and to understand programming in an extraordinary context. What if the improved programmability of the computer, in a broad sense, for many purposes, became a major goal for free software developers? Couldn’t we do a few orders of magnitude better, and allow for people to be even more empowered by the use (and programming) of computers?

Art as Process, BASIC Considered Helpful

Two quick interruptions to our unscheduled blog hiatus:

Francisco J. Ricardo of RISD’s Digital+Media Department has written a deep and detailed blog post, “From Objecthood to Processhood.” In it, he defends artists, their work, and their discourse about the digital, responding to Henry Jenkins’s 2000 article “Games, the New Lively Art,” which celebrates video games but isn’t as keen on the work of artists. He also describes the transition from a focus on the artwork, an object, to consideration of art as process, concluding with reference to my ppg256 series.

Also, a rather innovative defense of BASIC is advanced in “Where Dijkstra went wrong: the value of BASIC as a first programming language,” a post by Mike Taylor, who, by the way, has a totally sweet banner at the top of his blog. Edsger W. Dijkstra, who was my teacher at the University of Texas, is known for his work on structured programming and just about as well known for his quick denunciations of COBOL and BASIC. The post argues that BASIC is useful to programmers and allows them to discipline their thinking about programs. I would defend BASIC for a different, although not inconsistent, reason: The huge outpouring of innovative, diverse, creative programs – often very short ones – that were written in the 1970s and 1980s, making programming a widespread activity and showing people the potential of the computer for (among other things) amusement, simulation, play with language, and production of visual art. Noah Wardrip-Fruin and I wrote a bit more on this back in 2003 in our introduction to two BASIC programs on The New Media Reader CD-ROM.