From Portrait of a N00b, a great highly opinionated article about programming style and architecture. :
So you can write Java code that's object-oriented but C-like using arrays, vectors, linked lists, hashtables, and a minimal sprinkling of classes. Or you can spend years creating mountains of class hierarchies and volumes of UML in a heroic effort to tell people stories about all the great code you're going to write someday.It's a great long-form blog post / essay. Stephen Fry calls these 'blessays' which is preciously too close to 'bless' in English for me, but I like how it implies the French for 'to hurt'. Really good essays reveal a prejudice that you hadn't noticed in yourself, and either make you feel really bad about it or really good.Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done. It's not very easy to drag your heels and dicker with class modeling in dynamic languages, although I suppose some people still manage. By and large these languages (like C) force you to face the computation head-on. That makes them really unpopular with metadata-addicted n00bs. It's funny, but I used to get really pissed off at Larry Wall for calling Java programmers "babies". It turns out the situation is a little more complicated than that... but only a little.
And Haskell, OCaml and their ilk are part of a 45-year-old static-typing movement within academia to try to force people to model everything. Programmers hate that. These languages will never, ever enjoy any substantial commercial success, for the exact same reason the Semantic Web is a failure. You can't force people to provide metadata for everything they do. They'll hate you.
I spent the weekend doing massive refactoring of the S.O.S. in Ruby. On Sunday evening I changed gears and tried to rework a simple report for an older application in Java. The Ruby/Rails refactoring was exhausting, but the Java stuff, wrestling with 'convenience' classes I had built that now had to behave differently, was much harder. I kept thinking to myself "Why did I do all of this complicated class stuff for a simple report? If this was Ruby or PHP or whatever, I'd just toss together a hash and an array and have done with it. But no, that's not really the Java way. Besides the class way is cleaner." After reading this essay, I've realized that the class way is not actually cleaner - to make it 'easier' to sum up and group five columns, I had built two interrelated classes with dozens of JavaBean getters and setters, and several delegates to other methods, which have to be overridden for the new report. That's why I liked this part near the end:
I think the general answer to this is: when in doubt, don't model it. Just get the code written, make forward progress. Don't let yourself get bogged down with the details of modeling a helper class that you're creating for documentation purposes.Part of my Java problem is that this is an old application I built in Struts, and the tools for getting data onto a web page tend to be built around JavaBeans - if it doesn't have a getter, then it can't use any of the 'helpful' formatting tools. That's another example of the architecture getting in its own way. The key benefit of Ruby and Rails is that they managed to mostly avoid getting in their own way. I'm concerned that Rails may some day end up getting too large and bloated for its own good - but that's why there's Merb.