Code vs. Coder

I read a blog this morning, which got a few thoughts started (oh noes, not again!). Rich Skrenta argued that code is our enemy while Jeff Atwood replied that the code itself isn't the problem, but that the real problem is what you see in the mirror. This reminded me of the good professor John Hughes (who taught me Haskell 5 years ago!), who has along with Koen Classen and others, been writing on QuickCheck the past years. It has been rewritten a number of times, each time with more features but fewer LOCs (lines of codes). Bearing in mind that counting LOCs is regarded as a measurement of productivity, Hughes asks,

Have we had negative productivity? We do more with less code!

Another example would be in the newly released xmonad 0.2 where Don (dons) Stewart recently blogged about how he with fewer lines of code did more by moving some of the logic into the data structures. He used a technique called zipper (references in the end of his blog entry) and could thus merge two data structures into one, eliminating the problem of keeping them concise. Easier to write the code and less risk of writing bugs. Did he have negative productivity too? I would have to say no. Written code has to be maintained by someone, depending on what it was written to do. When GHC 6.6 was released the Gentoo Haskell Herd got busy as roughly half of the Haskell packages only compiled with GHC 6.4.2 (about 16 broken out of 40). Naturally we wanted them to work with GHC 6.6 too. It is hard to foresee what will change, no matter how you write the code, thus giving Skrenta a point. Code is the enemy. Reason for the broken packages (2) mostly was (in no particular order)

• deprecated modules and classes
• functionality moved to other modules
• changed type signatures
• changes in the type system?
• changes in the build system
• UTF8 trouble

All this makes me extra jumpy when Erik Hellman, a Java Consultant in Göteborg, blogs about when a 1400 lines game written in 50 min (in Swedish) which was later presented at the JavaOne conference. 500 lines are auto generated getters/setters, along with 900 manually written lines. Assuming writing the manual lines took 40 min, he wrote a line about every three seconds non-stop. I hardly think though that I even could write 900 lines in 40 min even by heart. He agrees, and notes that this is not possible without an IDE, in which case he recommends IntelliJ IDEA 6.0. Maybe Hellman is an extremely talented hacker and that his tools indeed are excellent, thus it's not possible to write the code in less than 1400 lines (in Java) and that it really should have taken some other programmer the whole day. Possibly the job has been solved and no one has to touch the code ever again. Personally though, I would be more interested to see how the game would evolve in 50 hours, days, or weeks. I guess it depends on what you want your app to do. Still impressive to write a game like that in 50 min, but 1400 LOCs? Hellman replies by saying that we are on the same track, and that we should see the other guy's code. How much logic can you write in 40 min? The resulting massive amount of code does not seem to be a problem. I guess that we just have different backgrounds. I have not yet had a look at the code, which recently was put online, but I do hope that the IDE will help to debug and maintain it. This raises the question of how many lines it would be in Haskell, given the corresponding libraries exists. Anyone want to give it a try?