The Code is Not the Point

There’s this meme in the programming community of thinking of our code as art. This is not a new phenomenon – it dates back at least to The Art of Computer Programming in 1968. More recently we have Paul Graham to thank for drawing the comparison between Hackers and Painters. With the rise of languages like Ruby and Processing and personalities like _why the lucky stiff programming has been gaining a reputation as an art form and a source of creative joy. And it should be. I love programming, it makes me feel good and I feel much better on days I’ve written code and produced something than on days I haven’t. However, I think the “code is art” or “programmers are artists” meme can be misleading because the code is not the point.

Miyamoto Musashi was a medieval Japanese swordsman and Ronin, widely regarded as the best swordsman of all time. He was also the author of a book titled “The Book of Five Rings” – a book on swordsmanship, strategy, tactics and philosophy that is still relevant today. There is one passage in the book that is relevant to our discussion:

The primary thing when you take a sword in your hands is your intention to cut the enemy, whatever the means. Whenever you parry, hit, spring, strike or touch the enemy’s cutting sword, you must cut the enemy in the same movement. It is essential to attain this. If you think only of hitting, springing, striking or touching the enemy, you will not be able actually to cut him.

The primary thing when you take an editor in your hands is your intention to solve the problem, whatever the means. Whether you write a script, a unit test, a function, or a library, you must move towards the solution in the same movement. It is essential to attain this. If you think only of scripts, tests, functions or libraries, you will not be able to actually solve the problem.

Because the code and it’s surrounding artifacts, including your sense of beauty, is not the point. It does not matter how much code you’ve written, what your test coverage is, how much you’ve learned in the process, if you haven’t not solved the problem (or solved it inadequately, or solved the wrong problem). Anything that does not bring you closer to your solution is suspect.

Does this mean that clean code, good comments, test coverage are not necessary or important? Of course not. If your code is not well-written and clear, are you sure you’ve solved the problem? If you have no tests, are you sure you’ve solved all aspects of the problem? If you have no documentation, how will others use and improve on your solution?

Does this mean that your code is not art? Does this you mean you should not carry an artists’ sense of elegance and aesthetics? Of course not. By all means take pride in your work. Make it a point of honor that others can understand your code without sending a dozen emails. Please aim for the solution that is not just correct, but also elegant, concise and efficient.

But keep in mind that the code is not the point. Beauty, elegance and pride are no substitutes for correctness. We are scientists and engineers first, artists second. If the theory does not fit the facts, if the code does not solve the problem, it must be discarded no matter how beautiful it is.

I don’t think of myself as an artist any more. My code is not art. I take pride in my work but it is the pride of an engineer. I want my code to have more in common with a Rolls Royce engine than it does with Sunflowers. I try to do the cleanest, most elegant job I can. But whenever I write code, the intention is to cut the enemy, whatever the means.

Real artists ship

It’s that time of the semester again when all the classes are reaching their climax, final projects and papers are rearing their ugly heads and you’re wondering where did the last three months go. I still have a good three weeks to go before finals hit, but at least for my independent study projects it’s time to wrap things up and call it a semester. I’ve been doing two independent projects: one pure computer science about parallel computation and another in art about data visualization. As you can probably tell from the title I’m going to be talking about the art project.

I decided to take up this project on something of a whim late last semester. I had been working with a particular art professor a few summers ago doing some interesting things related to computational art. That was an interesting experience but I hadn’t really thought about it for over a year. In that time I became increasingly interested in computer interfaces, design and digital art. The art I was thinking was not really painting or drawings in the generally understood sense of the term, but rather the use of visual elements (possibly interactive ones) to present data and convey a message.

I started the project with the idea that I would work on automated data visualization. There is a lot of data on the internet in the form of blog posts, websites, RSS feeds and of course the Twitter stream. I wanted to look at and come up with ways to build visual forms out of all this data that would allow people to both explore the datasets as well create visually appealing creative works.

As time went on, I realized that I really had no idea what I was doing. The data was out there, it was a bit of pain actually getting to, but with some time invested in strengthening my programming kung-fu I could build what I needed. The more pressing concern was that even with the data in hand, I didn’t really know how to go about turning it into visual form. Jonathan Harris’s wonderful We Feel Fine (and other projects) was really an inspiration for what I wanted to do, but it wasn’t quite enough. I wanted my visualizations to be informative as well as appealing. You would look at them and go “Wow, that’s cool” but you could also use the images created to come to important conclusions about the data that you had just visualized. And I had no clue how to do that.

So I started studying. Luckily for me, at the time the artist Loren Madsen was visiting Lafayette and I got to meet him, sit in on two lectures that he gave and talk to him over dinner. I was interested in his work and really liked the examples that he gave during his talk. When I talked to him over dinner I got to air my ideas and get some feedback from him and professors who were around at the time. It was also around this time that I discovered Edward Tufte. He is a person with really interesting ideas and four really beautiful self-published books. The more I read about him I realized that what I wanted to do was similar to the sort of things he did and talked about in his books. I even went to a class that he was teaching near Philadelphia and spent the better part of a sunny Tuesday learning straight from the man himself (I also got all 4 of his books). I just finished the draft of a 3500 word essay on Tufte and his ideas that will be online in the near future.

While all these ideas, concerns and questions were flying around in my head I had continual input from multiple professors about what to do, what to look at and what other people were doing or had done. A few weeks ago I buckled down, learned some JavaScript and built two simple interactive art pieces I call Typacolor and Readacolor. I’m still thinking about them, planning improvements and spinoffs (especially after talking to a professor yesterday). They don’t quite achieve the goal of allowing visual analysis of data, but they are a step on the way. I feel that my original goal is something that is going to take longer than a semester and significant improvements to my coding chops.

But as I trawled the intertubes looking for inspiration, ideas and things to talk about with my professors, I stumbled on yet another little phenomenon lurking in the wings: blogazines. Blogazines are in many ways a reaction to the template and theme driven look-and-feel of modern blogs and a return to more old school, handcrafted, standalone web pages but with the modern convenience of newer web technologies and better graphics. Heart Directed is a directory of blogazines (or art directed blogs) and looking through them I realized that visual presentation doesn’t have to be linked to actual graphics. The careful use of fonts, colors and images coupled with careful layout can create webpages that are as beautiful and capable of conveying an idea (or presenting data) as any image. I haven’t created any art-directed web pieces yet, but I’m kicking around a few ideas and hope to have at least done before the semester ends.

Coming to the end, I can say that this semester has been quite a journey. I learned a lot about art, graphics and the presentation of data. I learned that we can find beauty when we’re least expecting it. I also learned that I can’t learn new programming languages and technologies at the drop of a hat, but I can do a decent job when I devote sufficient time and energy (the interactive art pieces were built in an afternoon each). All in all, it’s been pretty worthwhile. I haven’t created as much cool stuff as I would have liked to, but I made up for that by learning a lot of things I didn’t think I would and meeting a number of very interesting people (and having lots of interesting conversations). Not too bad for my first art class.

The semester is coming to an end in less than a month, but my art expedition isn’t stopping. I’m heading to Italy for three weeks to be immersed in a completely different kind of art but at the same time. I’m going to be doing research on campus over the summer but I should have enough time to take up some interesting projects. In particular, I’m very impressed with the power of JavaScript to create art on the web (especially with Processing.js) so that is definitely something I’ll continue to do. And at some point I’ll finally get around to writing some sort of data visualizer for the web like I had originally planned to. My last independent study sparked an interest in programming languages that is probably going to take me to graduate school and I think this one is going to have a similar impact on my life in the next few years.

Lindenmayer Systems in Processing

Processing is a really powerful language and environment for programming images, animations and visual interactions. For the past few years I’ve had a passing interest in creating art using computation (thanks in no small part to a few great teachers). This semester I decided to buckle down and get to work doing some cool stuff with computational art. Just to get a feel of Processing and see what might be possible, I decided to revisit a project I had done a few years ago: Lindenmayer systems.

Lindenmayer systems or L-systems are pretty awesome. You start with a string of symbols and a bunch of rules describing how those symbols transform into other symbols. And then you just keep reapplying those rules over and over. L-systems can easily generate a wide variety of interesting forms and patterns including many plant morphologies.

Two years ago I made a  implementation of L-systems in Python using the Python Image Manipulation library. But one of the goals of that project was to create a tool that non-programmers can use. It was an interesting experiment, but after a few months I was no longer sure if it was a good idea to create a “non-programming” interface to something that is so computationally powerful. This time around I’ve eschewed the whole “pretty interface” idea in favor of dealing with real code.

I chose to use Processing so that I could work a few steps removed from nitty-gritty image manipulation. Processing is based on Java, so I can use Java with all it’s libraries if I need to (and to some extent, I did). I would have preferred it if I could have Python underneath, but I’m not complaining too much. There is also a version of Processing running on Scala and there is a port in the works to JavaScript and Canvas which I’m interested in. It might be an interesting future project to port it to Jython.

How it works

L-systems in general work by generating a string of symbols that work as driving instruction to a LOGO-style turtle (think of it as a pen you can move with simple instructions like “forward”, “left”, “backward” etc.). The lowermost layer is a simple turtle implementation that takes a bunch of movement commands and draws them to a screen (or canvas).

On top of that is a class that represents Lindenmayer systems in general. A class stores the symbols, rules and the mappings from symbols to turtle instructions. It also implements the basic rewriting algorithm and allows to provide an external turtle object (in case you want to process the image outside of the actual L-system). It also takes the generating string of symbols and passes it to the turtle to draw.

The top of the stack is functional Processing code where you have a setup() function that sets up the image canvas and initializes the L-System object. The draw() function executes repeatedly and controls how many generations the L-system goes through. Each L-system is two functions: a setup function that creates the L-system object with symbols and rules and another function that gets called on every draw(). This allows you to do extra processing before or after the L-system’s actual generation.

Go Get It

I’m calling the resulting system Lisip: LIndenmayer Systems In Processing. It’s released under a GNU GPL and is available right now on Github. There are just three source files (the Turtle, the L-System class and the Processing code driver which includes a number of L-systems). I think the code is fairly self-explanatory (thanks to a large extent to how much Processing cleans up the usual Java syntax). I do plan to add some proper documentation within the week.

I’ll continue to add L-systems to it and probably add to the Turtle’s functionality in the weeks to come. Feel free to fork it and add your systems, but I’d appreciate it if you dropped me a line if you do fork it.

Happy Hacking.

Ars Longa, Vita Brevis

I occasionally go and do something crazy, something completely unbecoming an engineer. Last semester I took an Creative Writing course with a most wonderful teacher. This semester I’m doing an independent study in art with an equally wonderful teacher. Last night I was up till about midnight getting the grip of Processing — a programming language and environment for creating stunning visuals. It’s a pretty sweet environment and I’ve only scratched the surface of what’s possible, but boy, was it hard.

All I did last night was recreate an project I’d done a few semesters ago with Lindenmeyer Systems. In some respects, our previous work was a bit misdirected and we should have been building on top of Processing all along. Last night I was reminded firsthand of the importance of using good tools suited for the task at hand. I didn’t write much in terms of code, but I did manage to build up a fair bit of functionality (a much better measure of progress I think). But it’s still not done and I suspect at least an hour or two more of steady work before I get to something that I can show off. This morning as I was trawling in the interwebs I came across this essay written by my creative writing professor and her quotation of “Ars longa, vita brevis” rang out as so true. The art is long and life is so short.

I’m not really an artist, though I like pretty things. I’m a hacker at heart. More important than the actual beauty of the object is the joy I feel in actually creating it. As  a coder, I guess I’m half decent by now. I’d call myself a really really advanced beginner (close to intermediate). But in terms of art, I’m pretty much a greenhorn. What’s more, the art that I’m doing is in code. I thought that would be fun and easy. It’s not easy and it remains to be seen if it’s fun. Though I love writing code and can concentrate better on writing code than on anything else, when it comes to art, I’m a bit lost. It’s been a while since I’ve done any drawing or painting, I prefer using my words to create images in people’s heads. Also without the use of hands and real physical paints and paper, it’s a bit harder to play around. Admittedly, it’s easier to tinker, redo and recreate with computerized tools but there is more of an upfront investment and the learning curve is significantly steeper (at least in the beginning).

In some ways, you could say that I’m painting entirely with mind. It’s liberating: I don’t have to worry about drawing a perfect circle or making sure that the sides of my squares are all the same length, the machine does it for me and I can work at a higher level. At the same time, I can’t just splash some paint on campus and see what it looks like. I have to look up an API reference instead of stroking away extra paint with a brush and I sometimes I have to get my hands dirty debugging (including dealing with Java’s broken type systems). If real artists did this all the time, we’d never progress beyond stick figures. That’s not to denigrate Processing, the people behind it or computational art. The gains in productivity and expression we get from tools like them far away my pain. Don’t mind me. I’m just bitching.

The art is long and life is short. It takes some 10,000 hours to become an expert in anything and it takes continued practice to keep up that level of expertise. And life is short. Sometimes I wish that I could sever all human contact and just sit and write code (or stories or whatever) and the next moment I realize that it’s stupid because it’s meaningless to live completely in isolation. There’s no point in my writing code or making art if no one uses and appreciates what I create. It’s rather ironic that it takes antisocial devotion to a task to create something that others can appreciate. If only our brains could really multitask, things would be so much easier.

Well, that’s enough bitching and moaning for one day. I’m going to get back to my code/art.