Programmers under the age of thirty probably don’t realize why Aged Senile Programmers like me are so slow to adopt exciting new programming languages the day they come out, and why we roll our eyes at hip bandwagon ideas that sell books and consulting engagements (forgive me if I don’t seem excited enough about your new book, “Extreme UML Refactoring Patterns”).
It’s probably because we read No Silver Bullet, a stunningly important essay from way back in 1986, by Frederick P. Brooks (he of Mythical Man-Month) that has proven again and again to be spot-on.
Programming consists of overcoming two things: accidental difficulties, things which are difficult because you happen to be using inadequate programming tools, and things which are actually difficult, which no programming tool or language is going to solve. An example of an accidental difficulty is manual memory management, e.g. “malloc” and “free,” or the singleton classes people create in Java because they don’t have top level functions. An example of something which is actually difficult is dealing with the subtle interactions between different parts of a program, for example, figuring out all the implications of a new feature that you just added.
Improvements in programming languages can eliminate accidental difficulties, but after you’ve done that, you’re left with the actual complexity of software development, so the No Silver Bullet theory basically warns us to expect diminishing returns from new technologies. I’m not really doing justice to Brooks’ argument, so if you haven’t read No Silver Bullet recently, I would highly recommend it.
There have been about five great advances, since the 1950s, in eliminating accidental difficulties in programming. These are, very broadly:
So the question is, what’s number 6?
Bruce Tate’s book Beyond Java tries to address that, and does a good job of explaining why so many experienced Java programmers are getting fed up with that language and moving to Python and Ruby.
Although Stevey lists lots of accidental difficulties in Java, when you read the book, you will notice a theme, which seems to be that it’s explicit typing, where the programmer is asked to declare the type of things, that leads to most of the problems. For example, the inability to express data in Java code is mostly just a side effect of the requirement that types be declared explicitly. Yes, there are other problems in Java, but this is The Big Hairy Problem right at the heart.
To a historian, it’s starting to look like type declarations are one of those accidental difficulties that good programming languages can eliminate. Beyond Java is a good summary of the arguments and worth reading.
You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.