Re: Microsoft and the two great blunders

Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<bsdbmu$c7iot$1_at_ID-152540.news.uni-berlin.de>...

> Table. Everybody and their grandmo know what a table is. Fore you, it is
> a relvar.But grandmo doesn't know what a relvar is.

My grandmother knows what a relation is, and it would be easy to explain her what a variable is. And of course she knows that a table is a board supported by several legs on which food is served :)

Relation is a common term out of the crazy IT world. Biz guys don't say: give me a table of customers.

But my main complaint is about using a single word for table value and table variable. They are fundamentally different concepts.

Table is more appropiate for the SQL bags, and relation is more appropiate if you are talking about a relational database.

> Where monadic is the incorrect name for unary tuple ?

Both are correct. I agree unary is more common.

>A
> relation is a set of tuples. Therefore a table may store all the
> values of a certain tuple type.

A relation is more than a set of tuples.

I have never seen a table containing all the values of a tuple type at practice. In many cases it would be physically impossible.

> So then the great blunder, it's not such a big deal, or is it ?

It does not have relationship with the great blunder.

> >>Quite nice. But according to D&D types are sets of values. Well, then a
> >>relation is a set of value.
> >
> > According to D&D and many other people, types can be viewed as sets of
> > values associated to sets of operators.
>
> Not unless they've written one more edition of The Third Manifesto where
> they corrected their mistakes.
>
> Here's a reference for you:
> http://www.hughdarwen.freeola.com/TheThirdManifesto.web/D.GRM
>
> As you may see, the user who declares a type has no mean to properly
> express a set of operators as integral part of the type definition.

Any operator may be a part of several types, and you can express that without problems with that template (and flawed) grammar.

(BTW is anybody interested on the mistakes of that grammar?)

Here is an appropiate quote:

-
A type is a defined finite set of values and associated operators. The associated operators consist of those defined to operate on values or variables of that type and those that, when invoked, return values of that type. -

http://www.hughdarwen.freeola.com/TheThirdManifesto.web/taamoti.paper.pdf

> Your definition "sets of values associated to sets of operators" is
> equally unsatisfactory. Does it mean that the definition of operators is
> integral part of type definition ?

Yes.

> Or to make it easier for you to express, here's an example from TTM:
>
> TYPE PLANE_FIGURE ... ;
>
> TYPE ELLIPSE
> IS PLANE_FIGURE
> POSSREP { A LENGTH, B LENGTH, CTR POINT };
It is not a complete type definition.

> Now, I wonder what you or anyone would replace those dots with, within
> the framework established by D&D, so that it makes any sense whatsoever.

Something like:

type Plane_Figure union;

I don't remember the syntax, my copy is 600 km far. It should be the equivalent of an "abstract" type.  

> But if the framework is so weak that it can't even deal with this much
> it should be either reformed or discarded altogether.

IMHO what is a bit weak is your knowledge of the model.

> > On the other hand, a relation
> > is an individual constant. But the "great blunder" is to confuse types
> > with relation variables, not whith relations (values).
>
> Nobody is confusing anything.

Then we live in different worlds.

Have you readed this:

http://www.ambysoft.com/persistenceLayer.pdf

It is the inspiration of dozens of SourceForge and comercial projects.  

> And this is no blunder. Most people *map* entity-types to tables. I.E.

Entity-types are virtually meaningless. Is the E/R "model" your idea of a formal framework? }:)

Most people "map" entity types to classes and classes to table variables.

> for every entity type found during analysis, they typically create a
> table in the relational schema to store values of that type.

That was before the persistence framework fad. Now they typically create a Java or C# class and they "map" the class to a table or several tables using a "persistence layer".

It is clear on the slides.

> I think a lot of people got confused by the lack of formalism in
> TTM, the lack of a practical formal system (implementation ) to play
> with and understand all the practical implication of D&D proposals.

I don't know any formal or serious criticism.

Many of the people that tried it I know say that it works amazingly well.

A little example:

http://www.dbdebunk.com/page/page/622317.htm

> >>According to proper type theory, a type is much more, of course.
> >
> > According to D&D too.
> >
>
> Not at all. See the above example.

See the above quote.

> To tell you frankly, I doubt that
> anyone has an exact (meaning formal) idea what a type really is,
> according to D&D.

I don't think that their intention was to give a very formal definition.

IMO Darwen's definition is enough to have a grasp on what a type in a programming language is.

I readed some of the references you gave (Cardelli's papers for instance), and I don't see fundamental differences.

> Like ? Can you name one data management principle that the poewpoint, I
> suspect, is against ?

One of the most important: Data must be managed by a DBMS.

They suggest that DBMSs could be replaced by XML file managers transparently.

> > The "Persistence Layer" approach leads to manage data in the
> > applications using network structures, to move from declarative code
> > to procedural code and to use DBMSes as mere file managers.
> >
>
> Move from what declarative code, to what procedural code ?

View and constraint definitions to procedures.

See any book from Ambler, Fowler, Larman, etc.

> I frankly was able to use a "persistence layer" without dealing with any
> network structures whatsoever, but then there are also bad examples in
> the Java world.

And I am able to map tables to applications without any "persistence layer" with almost no code lines.

So what is the sense of "persistence layers"? To maximize development and maintenance costs? I admit that they are great if it is your goal, and it is not a rare goal at practice. I know people who managed very well to convert a few hundreds of thousands euro project in a multi million project. And of course to make unmaintenable code that nobody wants to take on is a job continuing guarantee.

But in most cases I apply the principle which says: Don't attribute to malice what can be explained by stupidity.

> Since the powerpoint is about a future Microsoft product, which you
> probably haven't studied yet, the criticisim is invalid.

I know many similar products. SourceForge is plenty of them. Microsoft is only joining to the fad stream. Some of the typical blunders are crystal clear on the slides.

> Return to stone age from where ?

From the old client server systems which use a SQL DBMS like Oracle or DB2 and a "RAD" tool like Delphi, and from ADO.NET + SQL DBMS. And of course from Dataphor.

> Where were you or Microsoft from that
> matter so that a powerpoint will return you to stone age. I suspect you
> were in some place better ?

I am trying to be in some place better.

> Oh, common. Comp.database.theory has become a place where to unleash our
> rage against powerpoints ?

Against stone age data management approaches.

> It would be a much better effort to prove that something else can be
> done instead.

Agreed, I am working on that.

Usenet is a cigarette break for many of us who don't smoke or who work alone, and unfortunately rants are easier and faster than constructive stuff.

> Cheers and merry Christmas,
> Costin

Thanks, merry Christmas and happy new year for you too.   Alfredo Received on Thu Dec 25 2003 - 10:55:22 CET