Code is Beauty, Beauty Code

Friday 20 August 2010, 12:07 am   //////////  

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.

One-Line C64 BASIC Music

Monday 26 July 2010, 1:10 pm   ////////  

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.

@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, 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 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

H. Edward Roberts, Inventor of the Personal Computer

Saturday 3 April 2010, 7:53 pm   ////  
The inventor of the MITS Altair 8800, the inexpensive kit computer that is widely considered to be the first personal computer, has died at age 68.

PAX Blurb

Thursday 1 April 2010, 9:55 pm   ////////  

This weekend was a great time, both at the official PAX-East, where we saw the premiere of Get Lamp, and in the alternate but connected universe of the People’s Republic of Interactive Fiction Hospitality Suite, where Andrew Plotkin’s organizational acumen and contributions allowed us to hear panels, write and play Speed IF games, and snack and converse. The 2010 IF Summit at PAX-East was a great success. There and at the main expo, I got to speak with people from the contemporary IF community and many old-school IF luminaries from Infocom and before – and even got to be on a panel with several of them.

Dave Lebling, Don Woods, Brian Moriarty, Andrew Plotkin, Nick Montfort, Steve Meretzky, Jason Scott (standing, in absurd outfit). It is April Fool’s Day. Am I Photoshopped into this panel? Photo CC by Eric Havir.

And, I got to play on the proto-Ms. Pac Man board – the one Crazy Otto board that is known to still exist.

After PAX, I hosted a great reading of interactive fiction by Emily Short (who read from Alabaster) and Jeremy Freese (Violet), with interacting done by Kevin Jackson-Mead and Jenni Poladni. The event was at MIT (as with all Purple Blurb presentations), had standing room only, and prompted a great deal of good conversation afterwards.

There is much more that could be said, and many more PAX-East IF people that I could mention – a few of those, beyond the PR-IF regulars, are: Sam Kabo Ashwell, Liza Daly, Brendan Desilets, Stephen Granade, Juhana Leinonen, Jacqueline Lott, Jesse McGrew, Carl Muckenhoupt, Aaron Reed, Dan Schmidt, Robb Sherwin, Dan Shiovitz, Emily Short, and Rob Wheeler. (My apologies to those whose names I’m overlooking or don’t have on hand.) Some of these are locals I rarely see; others are people I have known for years, had numerous extensive discussions with, and in one case, collaborated with, and yet PAX-East was my first chance to meet them in person.

Based on last weekend and last Monday, the outlook for IF is extremely bright: We can share games and discuss important questions about IF in person as well as online, we have plenty of ideas that we’re making progress on but can certainly discuss further, and we have a documentary film coming on DVD that will please IF diehards and help to introduce students and other sympathetic viewers to the pleasures of the text adventure.

Big Day at DAC 2009

Monday 14 December 2009, 1:49 pm   ////////  

Ian Bogost and I just gave our talk “Platform Studies: Frequently Questioned Answers” here at Digital Arts and Culture in Irvine, California. There were three other talks – fascinating ones – in this day’s opening plenary session. Garnet Hertz took us into circuit bending, tactical media, and the artistic recycling and reuse of electronic waste. Jason Farman spoke on locative media with a focus on geocaching as technologically-enabled, embodied, proprioceptive play. Conor McGarrigle explored, in detail and with reference to several specific projects, the relationship between the practices of the Situationist International and contemporary locative media work.

Ian and I addressed six misconceptions about platform studies (the concept, the focus) which we’ve already heard a few times. Our talk was an attempt to better invite people to participate in the project and in the book series. In brief, the six misconceptions, and our responses, are:

#1 Platform studies entails technological determinism. Platform studies is opposed to “hard” determinism and invites us to continue to open the black box of technology in productive ways. #2 Platform studies is all about hardware. Platform studies includes software platforms as well. #3 Platform studies is all about video games. Platform studies extends to all computing platforms on which interesting creative work has been done. #4 Everything these days [in the Web 2.0 era] is a platform. We invite a focus on computational platforms, the basis for digital media work. #5 Platform studies is about technical details, not culture. Platform studies connects technical details to culture. #6 Platform studies means that everyone in digital media will have to get computer science training or leave the field. Platform studies shows how technical understanding can lead to new sorts of insights, but will not evict the many other important sorts of scholars from digital media.

The full paper is online, too. Since the beginning of the project, we’ve insisted on the embedding of the platform level in culture and other non-technical contexts, and we’re tried to draw connections between the way computing systems work and culture, history, and society. Others, we’re sure, will have new ways to do that; please, join us in taking up the platform as an focus for digital media studies.

I have one other collaborative paper today, which will be presented by Alex Mitchell: “”Shaping Stories and Building Worlds on Interactive Fiction Platforms.” Then I’ll present “The ppg256 Series of Minimal Poetry Generators.” Finally, I’ll be part of the DAC Literary Arts Extravaganza with a reading called “Five Uneasy Pieces.” I’m looking forward to it all, but I’m sure I’ll be glad to be looking back on it when the day’s done.

You can search Tweetland for #DAC2009 to see what the cool kids are saying about the conference.

IF, Visuality, and Other Bits of DAC

Among the many great presentations here at DAC 2009 at UC Irvine, the paper by Aaron Kashtan, “Because It’s Not There: Verbal Visuality and the Threat of Graphics in Interactive Fiction,” was particularly nice to hear. Aaron discussed my 2000 interactive fiction Ad Verbum, related it to Emily Short’s City of Secrets, and presented a nice argument about how these two engage (differently) with text’s ability to represent the visual. Here’s the abstract:

In this paper I analyze two contemporary works of interactive fiction (IF), Nick Montfort’s Ad Verbum and Emily Short’s City of Secrets, as examples of two contrasting ways in which IF reacts to the perceived threat of computer graphics. In the post-commercial era of IF, graphics represent a factor that, without being acknowledged, has profoundly shaped the development of the medium. Post-graphical works of IF may be distinguished according to how they respond to the threat or promise of graphics. Ad Verbum’s response to graphics is to emphasize the purely textual, and thus anti-graphical and anti-visual, aspects of the medium. The implication is that IF’s closest affinities are not with visual prose but with printed works of procedural textuality, and that IF is a visual medium. By contrast, City of Secrets activates a mode of visuality that depends less on immediate presence than on emotional affect and imaginative participation. Short suggests that IF is a visual medium, but that it differs from graphical video games in that its visuality depends on absence rather than presence.

I was also really impressed by Brett Camper’s discussion of the MSX-inspired “fake 8-bit” game La-Mulana and, on a very different level, the wide-ranging first talk of the conference, by Kate Hayles, which engaged cognition, tools, attention, and evolution.

DAC 2009 has proceedings which were handed out to attendees on CD-ROM and which will be (to some extent?) available. So, while I hope to mention a few more DAC highlights, I won’t aim to summarize talks.

The Deena Larsen Collection Opens

Wednesday 2 December 2009, 5:34 pm   /////////  

The Maryland Institute for Technology in the Humanities (MITH) has just announced a site showcasing the Deena Larsen Collection, which Deena gave to MITH in 2007. Early on, Deena wrote two Eastgate-published pieces, Marble Springs and Samplers, but these are only two of dozens of pieces she has developed individually and in collaboration over the years. In addition to creating e-lit for decades, she has amassed published and unpublished material from a wide range of e-lit authors along with many computers and print materials. MITH has also announced that they are now

opening the collection to scholars on a limited basis. Researchers interested in visiting Maryland to work with the Larsen materials on site should write to us at

Piksel09 Kicks Off in Bergen

Thursday 19 November 2009, 11:28 pm   ///////  

Piksel, a festival for free-software-creating and -using artists and developers, has begun in Bergen, Norway. If you can’t drop by, at least visit the festival on the Web and check out the brilliant hackery on display at the main exhibition.

A Tiny Poetry Generator with Blinkenlights

Thursday 3 September 2009, 3:31 pm   /////////  

ppg256-4 on a shelf

[As I wrote on] My latest Perl Poetry Generator in 256 Characters, ppg256-4, is my first one created specifically for a gallery setting. Although shown here in my office, it’s now on display at the Axiom Gallery for New and Experimental Media in Boston in the show Pulling Back the Curtain, which runs through September 27.

Since 2007, I have been developing Perl poetry generators that are 256 characters long. These programs constitute the ppg256 series. They are simply 256 characters of Perl code; they use no external data sources, online or local, and they do not make use of any special libraries or invoke any other programs. Here’s the code for ppg256-4:

perl -e 'sub c{$_=pop;$_[rand split]}sub w{c("b br d f fl l m p s tr w").c"ad ag ap at ay ip on ot ow"}{$|=print"\0\0\0\0\0\1Z00\2AA\33 b".c("be de mis re pre ").w." ".c("a on the that")." ".w.w.", ".c("boss bro buddy dogg dude guy man pal vato")."\4";sleep 4;redo}' > /dev/alpha

Note that those 256 characters of Perl include all of the control codes that are needed to drive the sign; the output is just redirected to the sign, a serial device, instead of appearing in the terminal. If you want to run ppg256-4 yourself, you can use this modified version that doesn’t include the control codes — it’s ready for you to copy and paste it into a terminal window:

perl -le 'sub c{$_=pop;$_[rand split]}sub w{c("b br d f fl l m p s tr w").c"ad ag ap at ay ip on ot ow"}{$|=print "\n".c("be de mis re pre ").w." ".c("a on the that")." ".w.w.", ".c("boss bro buddy dogg dude guy man pal vato")."\4";sleep 4;redo} #No LED sign version'

I’ll try to post a longer discussion about ppg256-4 on and/or on Post Position before too long.





This was posted here on Post Position for the convenience of those of you who subscribe to the feed or visit the site. If you want to leave a comment, please head over to this post on

Microchip Movers and Shakers

Friday 22 May 2009, 9:58 am   ///  

“25 Microchips That Shook the World,” an article by Brian R. Santo that was published this month in IEEE Spectrum, is a fascinating look at important hardware components and their historical influence – a look within various hardware platforms.

« Previous Page
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
(c) 2017 Post Position | Barecity theme