The Vietnam of computer science

Wednesday 28 June 2006This is more than 18 years old. Be careful.

The Vietnam of Computer Science is an interesting piece, on a number of levels. Ted Neward has undertaken to explain why Object Relational Mappers are difficult, and to illustrate his case, draws extensive analogies to the conflict in Vietnam.

It is a good (if dense) overview of the technical challenges involved in mediating between the relational model and the object model, and there are many. It even seems to be a good historical overview of the Vietnam War.

The problem, if I can get a little meta here, is that Neward has taken on a challenge he can’t neatly complete: to use Vietnam as a way to make the problems clearer. The hook is a good one, it’s very catchy, but he mires down his points with stretched analogies, and confusing references. There’s just way too much Vietnam in the piece:

Given that it’s impossible, then, to “unleash the objects to their fullest capabilities”, as General Westmoreland might call it, we’re left with some kind of hybrid object-to-relational mapping approach, ...

How does it help to pull Westmoreland into this? In fact, I glossed over the ten paragraphs of detailed history of the war. I get the big picture: ORMs have poorly-specified conflicting goals, and once you are drawn into using (or building!) one, things can get more difficult rather than easier, until you are experiencing diminishing returns.

Beyond that vague theme, the details of the war are merely a distraction from the computer science points (or is the ORM discussion a distraction from the Vietnam points?). In the end, the analogy is no help. Are we to look back on Vietnam and decide how it should have been handled, and do “the same thing” for our object/database interface? What is the appropriate analogy here?

And if we’re choosing a war to compare to, why choose Vietnam? Surely Iraq is the more interesting comparison. After all, we all agree about Vietnam, but the ORM conflict is still in full swing, with proponents of all sides heatedly pursuing their causes.

On the technical points, I like the discipline Ted Neward brings to the piece, including getting the root of “relational” right (it refers to the mathematical concept of a relation, which is a set of tuples, not to relationships expressed via foreign keys). I recommend you read about the tough technical challenges, and skip the Vietnam quagmire.

Neward also has posted some follow-up thoughts in response to criticisms of his post.

Comments

[gravatar]
I definitely agree with the premise about the glossed over problems and unclear goals of using ORMs, but the Vietnam analogy run out of steam. But I think the comparison would have worked if it weren't quite so detailed. All analogies are flawed when looked at too deeply, and he definitely argued analogy a little too deeply.

Jeff Atwoods blogged the same topic( codinghorror.com/blog/archives/000621.html ), there is an amusing discussion in the comments. Most pro ORM can be summed up thusly:

1. OOP is good.
2. Relational Databases are good
3. OOP + Relational databases == double plus good!

When you argue against point three, many people take it that you are actually instead arguing against 1 or 2. Why? I guess its hard to imagine that two good things might actually be LESS than the sum of its parts.
[gravatar]
After all, we all agree about Vietnam

That's a joke, right?
[gravatar]
Brian: I didn't mean it as a joke, but perhaps I didn't give it the care the sentiment deserved. I was criticizing the analogy to the Vietnam War. The debate over ORM technology rages on today, with numerous adherents on both sides of the debate.

While Vietnam may not be a cut-and-dried issue that we all agree on, the nature of the disagreement is not a good analogy. Many people agree that Vietnam turned into a quagmire with very different outcomes than were anticipated at the beginning.

The Iraq conflict may be a better analogy, though more charged, so even less appropriate for a technical article.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.