Ted Neward makes the unsurprising comment that some problems don't lend themselves that well to an OO solution:

The problem I have with the industry right now is stated rather simply: Not every problem we face lends itself to an object-oriented solution. For a large percentage of developers working today, that is an uncomfortable feeling, and thus gets repressed with a brutality normally reserved for hideous personality defects that we don't want to own up to. Whether we like it or not, however, the design space that EJB--and Spring--operate in is a space that doesn't lend itself to the object-oriented paradigm, and trying to pretend otherwise can lead us into all sorts of dangerous places.

Well, I'd say that there are fewer things of this nature than Ted seems to think there are. Take his example, for instance:

Consider another technology whose major architectural principles also don't follow an O-O slant, that being the HTTP and Servlet space. When you consider the major tenets of object-orientation, usually consisting of polymorphism, encapsulation and a methodology that demands fine-grained methods and objects ("No method should be longer than a page in your editor" and "No class' responsibilities should exceed what can be written on an index card" being two of the common aphorisms used to describe proper O-O design and implementation), it slowly dawns on you that servlets don't really follow that approach at all. In fact, if we were to compare a servlet's overall design, it smacks much more of a 3270 session, which is essentially a procedural space: requests are processed, per-session data used as part of that processing, generating results that are returned.

Well. Maybe Java developers go that way. I certainly don't. This blog server is implemented via servlets and SSP (Smalltalk Server Pages), and it certainly doesn't have servlets that have those problems. In fact, my servlets tend to have one responsibility and short methods. I rather suspect that this is a problem with Java developers that Ted is projecting back. You don't have to create crappy, kitchen sink servlets - it's just that most Java developers do.

Perhaps Java development culture, with it's not fully OO implementation, encourages non-OO thinking. Perhaps the legacy of C developers who never really went for objects has something to do it. In any case, I think Ted identifies the wrong problem here.