Re: Date's First Great Blunder

From: Alfredo Novoa <>
Date: Thu, 15 Apr 2004 12:28:08 GMT
Message-ID: <>

On Wed, 14 Apr 2004 11:27:23 -0500, "Dawn M. Wolthuis" <> wrote:

>Not to me, it isn't. Mathematical models are simply models/metaphores.

They are formal representations.

> The
>discipline of "doing" relational theory could be seen as mathematics, but
>the application of this mathematics to the discipline of application
>software development has to do with a belief that this mathematical model
>has something to do with the engineering effort underway.

It should not have relationship with beliefs. It is proven that it is simpler than the known alternatives.

>Yes, it is a shame that those fresh out of higher ed do seem dogmatic about
>both relational databases as being the best databases and OO as the best
>programming languages, based not on practice, but the sermons they have
>heard in the classroom and read in their text books.

Most if not all of the advocates of the network and hierarchical approaches never tried The Relational Model, thus their experience has little value. It is hard to practice with something never implemented.

> The advocates in both
>of these areas have a pitch that resonates with professors and/or text book
>writers & publishers. I think both OO and relational theory ought to be
>taught side by side with alternatives and pros & cons of each.

I agree, although they are independent. Relational theory is for data management and OO is for coding.

> There is not
>one correct mathematical model for data, metadata, nor functions (by
>whatever names).

But there is one best approach for data management.

>> What is evident is that the equation: type = variable does not work.
>I agree.

Then it is obvious that you disagree with class = type

>> A class is a type and a class definition is a type definition.
>> Many people confuse a class with its definition.
>Me, for exampe. The term is used both ways.

Indeed, it is the typical fuzzyness of OO. OO terms have many meanings and communication and precise thinking is very difficult.

> I prefer to think of a class
>as a specification for (that is, metadata regarding) a domain/type.

It does not change the things a lot. The equation: type specification = relvar is as blunderous as type = relvar.

>> A class being a type is a set (among other things).
>See how confusing that terminology is?

Yes, that's why I tend to avoid the "class" term and to use "type", "type definition" and "type implementation" instead.

Bad terminology leads to bad thinking.

>> No, code does not have any relationship with metadata.
>really? What about the declarative code that specifies constraints on the
>data -- is that metadata?

No, it is a way to represent metadata. You should not confuse the "thing" with one possible representation of the "thing".  

  Alfredo Received on Thu Apr 15 2004 - 14:28:08 CEST

Original text of this message