Tag: programming

Posted on

Shebang Bash at Babycastles, July 2

Shebang Bash is a two-part event at Babycastles (137 West 14th Street, Floor 2, New York City) on Thursday, July 2.

It'll be sort of like this reading in Saint Petersburg, but with projectors.
It’ll be sort of like this reading in Saint Petersburg, but with projectors and a workshop beforehand.

The workshop (beginning at 6pm) provides an opportunity for anyone to begin developing computational poetry by modifying existing programs. Those without programming experience are particularly encouraged to attend. Workshop participants will develop, share, and discuss their work. Participants must register in advance and bring their own notebook computer running Linux, Mac OS, or Windows. (A tablet or phone will not suffice; computers are not available at the gallery.) Those who wish to can show and/or read from their work during the second part of Shebang Bash, although presenting during the reading isn’t a requirement.

The reading (beginning at 8pm) will feature work from Nick Montfort’s #! (Counterpath, 2014), modified versions of Montfort’s “Taroko Gorge,” and poems developed just previously at the workshop. Montfort will read from several pieces in #!, will screen concrete poems from the book, will discuss the project of this book and his computational poetry practice, and will answer questions.

#! (pronounced “shebang”) is a book of programs and poems, consisting of short programs in Python, Perl, and Ruby followed by examples of their output. While the book is published by a small press that specializes in poetry, part of its heritage can be traced to BASIC programming books and magazines from the 1970s and 1980s. Copies will be available for sale at Shebang Bash.

Tickets to the reading will also be available at the door on the day of the event. For workshop tickets or to get reading tickets in advance, see the Eventbrite page.

Posted on

Translating E-Literature = Traduire la littérature numérique

The proceedings of the June 12-14, 2012 Paris conference on the translation of electronic literature are now online. These include a paper by Natalia Fedorova and myself, “Carrying across Language and Code.” The conference took place at Université Paris 8 Vincennes-Saint-Denis and Université Paris Diderot, and encouraged me and collaborators to undertake the Renderings project, the first phase of which is now onlne.

Posted on

#! Reviewed in ebr

To continue the trend of three-letter publications presenting reviews of #!, ebr (Electronic Book Review) has just published a review by John Cayley – an expert in electronic literature, an accomplished cybertext poet, a teacher of e-lit practices, and someone who has created digital work engaging with the writings of Samuel Beckett, among other things.

poetry_and_stuff_screenshot

It would be difficult to ask for as thoughtful and detailed a review as Cayley provided. Nevertheless, now that ABR and ebr have offered reviews, I do hope that IBR, OBR, and UBR will follow suit.

Posted on

#! Reviewed in ABR

Steven Wingate’s review of my book #! (pronouonced “Shebang,” Counterpath Press, 2014) appears in the current American Book Review and seems to be the first review in print.

Review of #! in ABR

I was very pleased to read it. Wingate discusses how the presentation of code provided a hook for understanding what programs do, much as bilingual editions allow a reader to learn more (at least a bit more) about a different language by skipping back and forth between recto and verso. An important goal of mine was to offer more access to computing and to show that code can be concise and open. I aimed to do this even as I wrore rather obscure and difficult programs, such as the ones in Perl, but certainly when writing Ruby and Python, the languages Wingate finds most pleasing.

Even better, Wingate modified “Through the Park” to create his own elliptical text generator with his own language. Modifying the code that’s there is a close reading of it indeed, just as the reader who memorizes a poem knows it better than someone who looks over it or reads it aloud once. I’m very glad that Wingate got into the programs & poems in #! so deeply and that he wrote this review. I’m sure it will help to open up new perspectives on code and poetry.

Posted on

Trope Tank Writer in Residence, Spring 2015

Andrew Plotkin, Writer in Residence at the Trope Tank for Spring 2015

This Spring, Andrew Plotkin (a.k.a. Zarf) is the Trope Tank’s writer in residence. Andy will be at the Trope Tank weekly to work on one or more of his inestimable projects — as a game-maker, programmer, and platform developer, he has been working furiously for many years. (His home page is modest in this respect; See also his latest game, Hadean Lands.)

Posted on

Renderings (phase 1) Published

For the past six months I’ve been working with six collaborators,

– Patsy Baudoin
– Andrew Campana
– Qianxun (Sally) Chen
– Aleksandra Małecka
– Piotr Marecki
– Erik Stayton

To translate e-lit, and for the most part computational literature works such as poetry generators, into English from other languages.

Cura: The Renderings project, phase 1

After a great deal of work that extends from searching for other-langauge pieces, through technical and computing development that includes porting, and also extends into the more usual issues assocaited with literary translation, the first phase of the Renderings project (13 works translated from 6 languages) has just been published in Fordham University’s literary journal, Cura.

Please take a look and spread the word. Those of us rooted in English do not have much opportunity to experience the world-wide computational work with langague that is happening. Our project is an attempt to rectify that.

Posted on

Some Houses of Dust

Zach Whalen pointed out that it would probably be interesting to compare the reimplementations of A House of Dust that he did early this year and that I did more recently. Whalen’s work to reimplement historical systems is really excellent, by the way, and I in fact showed his animated GIF of “Kick that Habit Man” when I premiered Memory Slam, including a workalike of Gysin and Sommerville’s program and my version of the Knowles and Tenney poem, at NYU ITP’s Code Poetry Slam.

While I’m not going to go deep into code-level analysis of these – that’s a better task for some other code scholar and code warrior – I will make a few high-level points about the two versions, to at least cover some of the obvious differences.

My implementation is much more flat, for better or worse.

Flat in terms of files; all the CSS and JavaScript used by my implementation is packed into the one HTML page, so it’s easy to save it to your desktop, change the file around quickly, and see the result. However, that’s not a very Enterprise way to go about it; Whalen’s version reflects more typical programming practices in that regard, linking to a standard CSS file used throughout the site and using JavaScript stashed in .js files.

My version is also flat also in terms of appearance. While I present the plain monochrome all-caps stanzas scrolling up, Whalen gives a Janus-like look backwards to the pinfeed fanfold paper on which the original poem was published and forwards to the world of social media, via the “Share” button. This is a visual reminder of how the original prinout looked (although it did have four spaces of indentation rather than one!) and an indication of how its output can be part of today’s systems of sharing. I chose to use a proportional font because the monospace font seems too austere and too severe of a historical reminder to me, but I’m glad there is Whalen’s monospace alternative as well. That the lines in Whalen’s version appear a bit at a time is also a nice printerly touch.

It’s an empirical question as to whose version is the most easily modifiable and remixable. One can change the strings around quite easily in both versions to attain new versions of the classic program, after all the files are obtained. I would guess (and hope) that my version might have the edge in providing this sort of flexibility to those exploring the poem through programming, whether new or experienced. If so, that might make it useful in this particular regard and make up for the less historicized appearance and less sharable output.

There was another point to my implementation, which was that it was done more or less uniformly with the other three pieces included in my Memory Slam. So, a new programmer working with any one of those would be more easily able to continue to work with other programs in the set.

That’s something of a start to the discussion of these. I certainly welcome further comments and comparisons.

Posted on

Z-Machine Implemented in Hardware

It happened to some extent with LISP, which certainly started out as a software programming language, and the LISP machines, which supported the language with hardware features.

Now, the Z-Machine, which was probably the first commercial virtual machine, developed in 1979 by Joel Berez and Marc Blank for Infocom, has been implemented in hardware using an FPGA. The Verilog code is available, so you can make your own if you like.

It all goes to show you … there is no software.

Posted on

A Great Platform Studies Answer

To how software keeps getting better and graphics get better-looking on the same old consoles.

Note that for the Atari VCS / Atari 2600, only answers #3 and #4 apply, since developers didn’t use “engines” or even compilers, instead writing their code in assembly langauge. (Presumably the assemblers didn’t improve much over the years.) Also, the VCS had no firmware, flashable or otherwise; although refined versions of the hardware were produced over the years, such as the Atari 2600 Jr., such systems were optimized for cheaper manufacturing and didn’t improve performance.

Still, there are important continuities between the answer to this question for the VCS and for modern-day consoles. And the answer is not obvious, since companies and the press usually emphasize the improvements in hardware that are made between generations of a console.

Posted on

A Gysin & Sommerville Question

I recently released Memory Slam, a set of four reimplementation of classic text generators. I did them over in JavaScript and in Python in the hopes that people would easily be able to play around with them, modify them, and understand them better through this sort of use. I’ve seen a few cases in which this has been done already, but first off, please let me know if you’ve posted modified versions of these, as I would love to see more. The license terms do not oblige you to do so, of course, they are licensed as free software. I’m just asking.

One question that remains is exactly when the program that automatically permuted phrases was written by Ian Sommerville in collaboration with Brion Gysin. I’m very interested in finding this out, but I do have other projects that are keeping me from doing archival or even deep library research into this. After discussion on the original announcement post, I’ve made a few corrections to this sort of metadata, but I still can’t figure out when this permutation code was first written. And since I don’t know which texts are the first examples of output from these programs, I also can’t tell how the permutations were ordered by the program.

The poem “KICK THAT HABIT MAN” was written manually in 1959 and other permutation poems were broadcast by the BBC in 1960. “Around 1960” is sometimes given as a date for the program or programs. However the Honeywell Series 200 Model 120, indicated in several places as the computer used, was not released until 1965. Please let me know if you know that a different computer was used or if you know the exact year in which the permutation poem programs were written.

And I can’t post something about these friends of William S. Burroughs, on Thanksgiving, without including this little prayer:

Posted on

#! in San Antonio Fri 11/21 – #! in Austin Sat 11/22

I’m doing two Central Texas readings from my book of programs and poems #! this weekend:

San Antonio: The Twig Book Shop

Friday, Nov 21 at 5pm
The Twig Book Shop
in The Pearl (306 Pearl Parkway, Suite 106)

Austin: Monkeywrench Books

Saturday, Nov 22 at 4pm
Monkeywrench Books
(110 N Loop Blvd E)

#! (pronounced “shebang”) consists of poetic texts that are presented alongside the short computer programs that generated them. The poems, in new and existing forms, are inquiries into the features that make poetry recognizable as such, into code and computation, into ellipsis, and into the alphabet. Computer-generated poems have been composed by Brion Gysin and Ian Sommerville, Alison Knowles and James Tenney, Hugh Kenner and Joseph P. O’Rourke, Charles O. Hartman, and others. The works in #! engage with this tradition of more than 50 years and with constrained and conceptual writing. The book’s source code is also offered as free software. All of the text-generating code is presented so that it, too, can be read; it is all also made freely available for use in anyone’s future poetic projects.

Nick Montfort’s digital writing projects include Sea and Spar Between (with Stephanie Strickland) and The Deletionist (with Amaranth Borsuk and Jesper Juul). He developed the interactive fiction system Curveship and (with international collaborators) the large-scale story generation system Slant; was part of the group blog Grand Text Auto; wrote Ream, a 500-page poem, on a single day; organized Mystery House Taken Over, a collaborative “occupation” of a classic game; wrote Implementation, a novel on stickers, with Scott Rettberg; and wrote and programmed the interactive fictions Winchester’s Nightmare, Ad Verbum, and Book and Volume.

Montfort wrote the book of poems Riddle & Bind and co-wrote 2002: A Palindrome Story with Willliam Gillespie. The MIT Press has published four of Montfort’s collaborative and individually-authored books: The New Media Reader, Twisty Little Passages, Racing the Beam, and most recently 10 PRINT CHR$(205.5+RND(1)); : GOTO 10, a collaboration with nine other authors that Montfort organized. He is faculty advisor for the Electronic Literature Organization, whose Electronic Literature Collection Volume 1 he co-edited, and is associate professor of digital media at MIT.

#!Nick Montfort

Posted on

Forbidden

You don’t have permission to access /memslam/IN A GREEN, MOSSY TERRAIN,IN AN OVERPOPULATED AREA,BY THE SEA,BY AN ABANDONED LAKE,IN A DESERTED FACTORY,IN DENSE WOODS,IN JAPAN,AMONG SMALL HILLS,IN SOUTHERN FRANCE,AMONG HIGH MOUNTAINS,ON AN ISLAND,IN A COLD, WINDY CLIMATE,IN A PLACE WITH BOTH HEAVY RAIN AND BRIGHT SUN,IN A DESERTED AIRPORT,IN A HOT CLIMATE,INSIDE A MOUNTAIN,ON THE SEA,IN MICHIGAN,IN HEAVY JUNGLE UNDERGROWTH,IN AN OVERPOPULATED AREA,BY A RIVER,AMONG OTHER HOUSES,IN A DESERTED CHURCH,IN A METROPOLIS,UNDERWATER on this server.

Posted on

Memory Slam and Code Poetry at ITP

I was delighted to be at the first NYU ITP Code Poetry Slam a few hours ago, on the evening of November 14, 2014. The work presented was quite various and also very compelling. Although I had an idea of what was to come (as a judge who had seen many of the entires) the performances and readings exceeded my high expectations.

A reading I did from historical computational poetry kicked off the event. I read from a new set of reimplementations, in JavaScript and Python, that I developed for the occasion. The set of four pages/Python programs is called Memory Slam. It contains:

Love Letters
Christopher Strachey, 1952

Stochastic Texts
Theo Lutz, 1959

Permutation Poems
Brion Gysin & Ian Somerville, 1960

A House of Dust
Alison Knowles & James Tenney, 1967

These are well-known pieces, at least among the few of us who are into early computational poetry. (Chris Funkhouser and his Prehistorical Digital Poetry is one reason we know these and their importance; Noah Wardrip-Fruin has also offered a great discussion of Love Letters, and Stephanie Strickland, who was in attendance at the slam, has done two collaborative poems based on A House of Dust, one with me and one with Ian Hatcher.) Some implementations exist already of many, perhaps all of them – although I did not find one for A House of Dust. My point in putting these together was not to do something unprecedented, but to provide reasonably clean, easily modifiable versions in two of today’s well-known languages. This will hopefully allow people, even without programming background, to learn about these programs through playing with them.

If I didn’t implement everything perfectly, these are explicitly free software and you should feel free to not only play with them but to improve them as well.