A Newbie's Rant

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.


Comments:

You are forgetting about two things:

1) maintainability - it doesn't matter how efficient or speedy your code is if nobody except for you can understand it and work with it. Actually I often realize that whenever I sacrifice maintainability, two weeks later I have problems to work with my own code.

2) productivity - there is so much code that needs to be written and there are only so many skilled developers to do it. HW is cheap, a lot cheaper than valuable time of developers. So unless your app really needs to fly, it is IMO a much better choice to write it in a slow but highly productive language or framework, than spend days and weeks using the better performing but more complex framework/language/pattern.

If you put these two factors into the equation, you might better understand what DHH meant.

Don't take it wrong, I'm a performance freak, but that doesn't mean that I'm going to waste time on tuning every line of code I write. A lot smarter people than me said that premature optimization is the source of most of the evil and I so often witness that that's very true.

Posted by Igor Minar on May 12, 2009 at 11:22 AM PDT #

For me, clear code is maintainable code, I'm sorry if I didn't make that clear. I'm certainly not advocating performance over all else (or premature optimization), just that performance and language choice don't need to be sacrificed for programmer happiness: They should compliment, not oppose each other, because writing clear, elegant, performant code in /any/ language should make you, as a programmer, happy.

Posted by Jacob Kessler on May 13, 2009 at 03:05 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Jacob Kessler

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today