A Newbie's Rant
By Jacob Kessler on May 12, 2009
So, I know that, compared to David Heinemeier Hansson, I'm a newbie. He's been programming professionally since I graduated high school, written Rails, and shown himself to generally be an exceptionally competent programmer. None of this rant is meant as an attack on who he is, or what he has done.
That said, I have to respectfully disagree with a statement in his latest blog (which itself seems to be part of a larger "profession vs. artist" debate ignited at RailsConf this year). He said, talking about the Ruby community,
People waxing lyrically about beautiful code and its sensibilities. People willing to trade the hard scientific measurements such as memory footprint and runtime speed for something so ephemeral as programmer happiness.
To me, that statement conflicts with one of my core beliefs about programming and programmers: If you are a programmer, then writing fast, efficient, beautiful code should make you happy. It should be the thing that you strive for whenever you put fingers to keyboard or pen to white board. When you trade memory footprint and runtime speed for programmer happiness, are you really happy about the programming, or that the programming is complete?
That is not to say, of course, that memory footprint and runtime speed can't be traded, that they are sacred objects that must be held above all else. If they were, I'd be advocating programming in nothing but assembly (or maybe C), railing against object-oriented languages, and muttering about things being better before we had learned that computers generate code from high-level languages that is better than hand-optimized assembly code.
What I am saying, though, is that code that is fast and memory efficient is beautiful, and beautiful code is fast and memory efficient, and that, if you are a programmer, writing beautiful code should make you happy. Code should have a clearly-defined purpose, and it should fulfill that purpose efficiently, cleanly, and elegantly. It's quite possible to write code that will sacrifice any of those (particularly clarity) in the name of memory footprint or runtime speed. But often, such sacrifices are sacrifices in name only: The final product doesn't use much less memory or run much faster, if at all. Indeed, if you have a clear, elegant solution that isn't efficient, you've likely made a mistake somewhere, and mistaken the simplicity of bubble sort for the elegance of heap sort.
That bears re-iterating: clear, efficient, clean, elegant code is
not the same as simple code, since many people seem to mix those up.
Sometimes a complicated solution is the right way, as long as its
purpose is clear once it is written. Sometimes the answer is A\*, even
though it is more complicated than Dijkstra's algorithm.
This is not, of course, to say that Ruby is not a beautiful language, just because it's not as fast or efficient as other languages. Ruby can be beautiful. But so can Java, and Lisp, and maybe even Python and C. The beauty is in the code, not the language. The beauty is in how you use the language to solve the problem clearly, cleanly, efficiently, and elegantly.
To wander back around to the point I originally had, memory footprint and runtime speed aren't sacrificed for programmer happiness. They contribute to it. Creating something that is clear, clean, efficient, and elegant will be both fast and beautiful, and that beauty should make you happy. Simply finishing the programming shouldn't. Finishing the program with last-minute additions duct-taped to the side shouldn't. Creating a single, well-integrated, efficient program that does its job well should. Creating a program that can easily contribute to something larger, without sacrificing its own beauty should. Solving difficult problems in clever ways should. You shouldn't rely on the language to create happiness, you should rely on the problems that you are solving with the language to create happiness. And you shouldn't mistake "easy" for beauty or happiness.