Re: Ah, but who has better parties?

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Fri, 14 May 2004 08:30:06 -0500
Message-ID: <c82hle$7tn$1_at_news.netins.net>


"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:Vj3pc.636$kt2.578_at_newssvr33.news.prodigy.com...
> "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.

Agreed. And that is how the "relational revolution" took place. In fact, there are still folks who think that they must move to SQL Server because it is both relational and Microsoft -- quite the scary marriage from my perspective.

> In that respect, Pick and MV have
> a better argument than XML - they're far from cool. :-)

You've got that right too!

> 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.

Disagree.

>

> 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.

Agreed.

> > 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... :-)

Too many "selfs" involved. You are smart and I used to be ;-) and we would arrive at different conclusions in many cases. If it is too complex to test our theories, then I suspect the industry would be better served by relying on intuition based on experience rather than designing elegant algebras and then tossing an implementation into production with an assumption it will be a good workhorse.

> > 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.

If it were static, perhaps.

> > 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.

Yes, I suspect that is the case, but it sure could provide some better information to help companies decide where to spend their dollars.

> Every piece of software we write is a theory, and uses a language that has
> its own theory.

To the same extent that every sentence we say has its own "theory". Whether we understand what that or those theories might be when we say it is unimportant. My father analyzes jokes (knowing precisely how to kill a good laugh with that "do you know why that's funny" line). I suspect that John Stewart, Jay Leno, and George Carlin do know some good patterns to jokes as they design them, but I suspect some come to them before they analyze the structure, so that they were not designed for humor, but once they were determined to be funny, the humor could be analyzed. That's what I'm doing with PICK. The comedians who design data for PICK have collected some patterns that are particularly good, but they might not always know precisely which rule they are using when choosing the data design -- they are just naturally funny people.

> 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.

I'm all for designing software -- don't get me wrong on that, but sometimes the jokes that were not written to some rule for humor, but just flow from a person, are the best jokes. --dawn Received on Fri May 14 2004 - 15:30:06 CEST

Original text of this message