[jhancock]

I agree with Atwood's conclusion here. If you must use both an OO second tier and a RDB 3rd tier, concessions must be made. You can get around most concessions with more code at the hard parts, but sometimes its just not worth the effort. In addition to these concessions, there have been choices of OODBs for quite a while. We are now seeing some new DB choices come on the scene.

My perspective comes from having written what may have been the world's first ORM in Smalltalk in '88. I then spent the next 14 years building them over and over along with a full stack of other frameworks in Smalltalk and Java. Choices must be made. No framework is one size fits all. I generally sided with "make the easy things easy/automated and make the hard things possible/maintainable".

Is it Vietnam? No. You have far easier choices in how to develop your app than soldiers did in choosing wether or not to go to Vietnam. I wrote very hard ORM and other framework code; solved problems that enabled my customer's projects to be far more productive; was paid very well; enjoyed a good life; worked hard and was respected for my contributions. Hardly Vietnam.

[wyw]

I think the comparison to Vietnam makes sense as an analogy.

The basic argument seems to be that each ORM imposes limitations specific to that implementation which may result in the developer's choices being limited later on in the development process - just as early strategic decisions in a war can predetermine the outcome and potentially result in 'quagmire'.

It's an argument that seems to echo Joel's idea of "leaky abstractions", i.e. the ORM is just a big leaky abstraction and you have to deal with the leaks sooner or later.

[jhancock]

The arguments in Atwood's and Neward's articles stand well on their own. The war analogy is there as link bait.

[wyw]

If anyone could be accused of linkbaiting it would be Neward since he wrote the original article titled "The Vietnam of Computer Science". But I think it's less useful to think of the war analogy as linkbait than as a didactic tool to bring attention to aspects of ORM use that Neward wished to highlight. Creating effective analogies is the same strategy used by good teachers the world over.

[jhancock]

The first thing wrong with this title is the article is about "software engineering", not "computer science". The second thing wrong is engineering is a discipline that teaches you about trade-offs, costs, and finding balance in your solutions.

I had excellent engineering teachers. Never once did they compare the tough problems we were solving to Vietnam.

[wyw]

Maybe they didn't compare tough problems to Vietnam but my point was that good teachers often have a knack for translating difficult-to-grasp abstract concepts into the familiar and the concrete. Some people look down on such teachers and accuse them of dumbing things down. I would say on the contrary that the job of a teacher is exactly to dumb things down.

[fauigerzigerk]

The Vietnam analogy is bad in many respects but I can see where they're coming from. ORM was a battlefield, many faught hard (including myself) and ended up walking way disgusted and defeated at the same time.

[wyw]

In what respects is the Vietnam analogy less meaningful than the rather banal battlefield analogy that you just made?

[fauigerzigerk]

I didn't mean to say that it was less meaningful. My battlefield was meant to be a Vietnam battlefield, not some alternative or better analogy. I'm defending Neward's analogy up to a point. Any war analogy of course misses the humanitarian horror that is a war. That's why it's always a problematic analogy as well.