Re: Date's First Great Blunder

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:407e7725.5656954_at_news.wanadoo.es...
> On Wed, 14 Apr 2004 11:27:23 -0500, "Dawn M. Wolthuis"
> <dwolt_at_tincat-group.com> wrote:
>
> >Not to me, it isn't. Mathematical models are simply models/metaphores.
>
> They are formal representations.

Yes, formal representations of a metaphore for whatever in the "real world" they are applied to

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

Simpler to human beings? Simpler to computers? Simpler to work with mathematically? This is a RELIGIOUS BELIEF that if you take the simplest mathematical model (aka metaphor) for something, then that is the best. I could use a point as a mathematical model for God or use a more complicated model of a triangle. I prefer the triangle metaphor because it is helpful for describing a trinitarian view of God. A point is surely simpler than a triangle, however. That doesn't mean it is the best metaphor to choose.

> >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 terms "Network" and "Hierarchical" were coined by relational theorists to disparage other approaches -- in other words, they are marketing terms. There are many people who persist data in trees (see your average file system, LDAP, DNS and many other repositories) or di-graphs (see the www).

I am an example of someone who has used Oracle, SQL Server, My SQL, and PostgreSQL and much prefer the data model of the U2 databases (UniVerse and UniData). Why? Because I care about the cost of ownership for the overall software solutions over time. I am not alone in knowing and using relational databases and prefering not to.

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

Yes, but both are for developing software applications that meet the needs of people and organizations.

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

Ah, there is that religion again -- I suppose the one best approach is to use the relational model? Yes that is king of the hill still in 2004, but it might be wise to keep your eye on the rear view mirror (to mix metaphors).

> >> What is evident is that the equation: type = variable does not work.
> >
> >I agree.
>
> Then it is obvious that you disagree with class = type

That's really a matter of defining terms. I do think that "the code is the spec" for software and by my definitions, the software class is a spec for a type. I think Eric had some more industry-standard terms for a difference between a specification for a set and the enumeration of the set. If I were to specify in a class that a set

S = {all women over 60}

then that class would have the specification for the type S but would not BE the type if, indeed, type and domain are the same set. My mother would be IN that set, but would not be part of the class, nor perhaps even within a 100 miles of the set.

The objects that can be instantiated by a class are NOT "in" the class, while they are in the domain specified by the class. But again, this is a definition of terms. I someone wants to define class=type then I can play that game but I'd rather say that a class is a type definition or specification.

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

But if all those OO folks have that same problem, then perhaps there is more precision than we think?

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

Is there such a thing as a relation as a type of attribute (as in "relational-valued attribute")? If so, then why couldn't a class be a type of relation?

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

OK, I can work with that.

> Bad terminology leads to bad thinking.

Agreed. "Bad terminology" is not just imprecise terminology but terminology that does not properly communicate. It seems to me that when I talk about classes with OO folks there is better understanding about what we are talking about than if I talk about types with relational database folks, however, the relational theorists have done a better job of making the definitions precise (each variation on them).

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

then we are back to a class not actually BEING a type, but being a possible representation of a type. Even though we have had a similar discussion on these terms many times in this forum, I'm not getting any wiser about them and I really want to. It is not just that there are so many possible definitions, but there seems to be different term-tuples that are being described. The question of "for what concepts do we need a term" are different in different worlds, so we have overloaded and contradictory terms. Some of that is understandable, but as soon as someone says that "OOclass=RELATIONALtype" it seems like things get muddier (in my head) and not clearer. I'll keep studying. --dawn Received on Thu Apr 15 2004 - 19:18:17 CEST