Re: Ah, but who has better parties?

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c81cqm$k4v$1_at_news.netins.net...
>
> "Leandro Guimarães Faria Corsetti Dutra" <leandro_at_dutra.fastmail.fm> wrote
> in message news:pan.2004.05.14.01.31.06.708198_at_dutra.fastmail.fm...
> > Em Thu, 13 May 2004 16:16:11 -0700, Paul G. Brown escreveu:
> >
> > > I'm ain't Anglo-Saxon (close though) but it's precisely my infatuation
> > > with pragmatism that *interests* me in the R model.
> >
> > I am not saying the RM isn't pragmatical, rather that the
> > attitude that everything must be practical is short-sighted and
> > counterproductive.
>
> That sounds like me as a grad student. I agree that not everything must
be
> practical and I also recognize that something that appears to have no
> practical use today might solve world hunger tomorrow. And from that
> perspective, I think research related to relational theory is important. I
> also think there are some aspects of that theory that are practical today.
> But there are some aspects of relational theory that have been applied and
> there is really no proof that they have helped the software profession in
> any way.

Like there's any proof for anything else? Let's weaken this statement and just say "evidence". I still say that this industry is driven far more by fads and what's "cool" than actual value. In that respect, Pick and MV have a better argument than XML - they're far from cool. :-) In any event, studies of such proof of value for the "software profession" (and, I assume, its customers) are notoriously difficult. I wonder how other engineering disciplines have coped with fads and "cool" technologies vs. the tried-and-true, which are based not only on theory but on standardized components (boring though that may be).

Obviously comparisons with other engineering disciplines can only go so far. Given that software development has a much greater opportunity to stick close to theory (since models of buildings are just that, while models of software are... software), and because I believe that most disciplines would (or should) deviate from theory only as needed, we should adhere to theory a bit longer.

There's a difference between abandoning a theory in favor of an implementation because the theory falls short, and abandoning it because, well, the implementation is a cool new toy. I think that drives far more of this industry than we'd like to admit.

> Relational theory in a vaccuum is someone else's game (not mine, but
likely
> yours) and have at it -- advance it and learn new things about it, but
> please don't force practitioners to use it until it is better than
whatever
> else is there.

I guess "self-evident" is unsufficient justification... :-)

> Please test those drugs before you get us addicted to them.
> It is just too costly to go from the "hey, this theory holds together
> mathematically" to "companies should use products that implement aspects
of
> this theory because we know it is good for them" without adequate testing.

"Aspects of this theory" is the problem, as it results in novel and flawed products and sullies the reputation of the theory. SQL implements "aspects of" relational theory. When a theory is fairly compact and domain-restricted (as relational is), implementing it in its entirety isn't quite the difficulty it sounds like.

> Emperical data to prove that such things as 1NF are good for us (the
> software development industry and our users) seems to me to be the
> responsible thing for us (as an industry) to collect before we go and
stick
> it to the world with implementations of untested theories.

And I disagree that such is even possible, though I'm admittedly not a scientist trained in constructing studies like this. If it were possible, it would be disagreed on as much as the theory itself.

Every piece of software we write is a theory, and uses a language that has its own theory. There's precious little difference between what we do and logic and math - far less than any other discipline (and Dijkstra would have argued even less than those of logicians and mathematicians!). It's like design: your software will have one. You can either think about it and use it, or just not think about it and end up with one you don't know or understand, and which is expressed in a sloppy, implicit way.

> just an opinion, of course. smiles. --dawn

Sure, understood...

• erk