What if Dylan wrote in Dylan?
If you have a Twitter account, you probably noticed the recent avalanche of messages tagged with #songsincode. If you missed it, you can follow the trend here. The premise is simple: rewrite the lyrics of a song in a programming language. For example, I’ll start you with an easy one:
This, of course, is the opening of Bob Marley’s “No Woman, No Cry” written in Groovy. Here’s another one:
If you guessed “(If you can’t be with the one you love) Love the One You’re With” by Crosby, Stills, and Nash, I can only give you partial credit—technically, it was a solo release by Stephen Stills. Here’s one more:
If you didn’t recognize “I am the Walrus” by the Beatles, go back and check out the lyrics on the original dust jacket of “The Magical Mystery Tour.” Since Groovy hadn’t been invented yet, John Lennon was forced to write the lyrics in BASIC:
The real fun of this Twitter meme is not only looking at people’s choice of programming language, but looking at their taste in music as well. (“Karma Chameleon” in Ruby? Really? REALLY?!?)
But as I read one nearly indecipherable post after the next, a discouraging realization hit me—this is what we do for a living. We translate user stories into source code. How much of it survives the operation? More importantly, how much of it gets lost in the translation? If #songsincode is in any way representative of the best that we can do, we’re in big trouble.
Moving beyond music for a moment, take the case of Google Maps. There is something deeply beautiful about the way you simply drag the map around to navigate. But is that beauty evident in the implementation?
The beauty of this:
...is the Twinkling Little Star that gets rendered by the browser, not the HTML markup itself.
This example also demonstrates that we, as programmers, are more transliterators than translators. Transliteration is “using the closest corresponding letters of a different alphabet.” Since HTML offers neither “twinkle” nor “little,” “<blink>” and “<span style>” will have to suffice.
And that is the joy of programming in a nutshell. How well do you transliterate the user story into code, bridging the gap between the technical (expressive?) limitations of the programming language and the English prose of the request? The joy is in the puzzle solving.
Musicians do it all the time. Ask Bob Dylan to explain life... in eight lines... that rhyme. He’ll reply (in “Subterranean Homesick Blues”):
Now ask yourself, “How many Bob Dylan albums do I have in my iTunes library?” (Please feel free to transliterate “Bob Dylan” and “iTunes” into the artist and software of your choice.) Here’s my response, in Groovy:
And for the record, here are the results:
As soon as I finished writing the code, I started asking myself questions:
Should I replace “Bob Dylan” with “args” so that I can pass in any artist from the command line?
Is there a simple way to return the list of albums chronologically instead of alphabetically?
Where did Bob Dylan’s “Greatest Hits” album go? D’oh! I lost all of the albums named “Greatest Hits” except for the last one since key values in HashMaps must be unique. Looks like I need a unit test and a new way to store albums.
You were most likely asking yourself a different set of questions as you read my solution—“Why did he choose Dylan instead of Metallica (or Snoop Dogg) to explain life?” and “Why did he choose Groovy instead of [my language of choice] to walk the iTunes directory?” I’m sure that you could find more beautiful answers to each question. In both music and programming languages, there’s no accounting for taste.
But at least in the case of programming languages, you can frame the question in terms of appropriateness for the task at hand.
Stuart Halloway (author of Programming Clojure) wrote a series of articles called “Java.next.” The first three articles compared solutions written in Groovy, JRuby, Scala, and Clojure. Each showed dramatic improvements over the baseline Java example—not just in a reduction in gross lines of code, but in clarity as well. But then in the fourth article, Stuart tackled immutability. This time, he narrowed the field to just examples written in Scala and Clojure. Here is how he explained his decision:
“Could you write the example above in Groovy, JRuby, or even Java? Yes, but it would be non-idiomatic, even ugly.... Languages are not about what they make possible, but about what they make beautiful.”
So perhaps the lack of beauty in the #songsincode transliterations was due to using the wrong language for the job. Said another way, clearly the humor in each #songsincode post rests squarely in the awkward transliteration. I doubt that Dylan (the singer) could sound any better, even written in Dylan (the programming language).
But let me leave you with one final thought: the end user only gets to see one dimension of beauty—the result of the running code. If you do it right, the beauty you see is multifaceted. If the code (as it runs) is as beautiful as the code (as it is written), then you are singing it just right.
Scott Davis is an internationally recognized author, speaker, and software developer. His books include Groovy Recipes: Greasing the Wheels of Java, GIS for Web Developers: Adding Where to Your Application, The Google Maps API, and JBoss At Work (co-author). Keep up with Scott at thirstyhead.com.