Re: Paper: Database Programming Languages

Op donderdag 5 februari 2015 09:05:27 UTC+1 schreef Derek Asirvadem:
> Jan
>
> > On Wednesday, 4 February 2015 23:27:57 UTC+11, Jan Hidders wrote:
> > Op woensdag 4 februari 2015 06:44:36 UTC+1 schreef Derek Asirvadem:
>
> Thank you for your response.
>
> > It's end of my lunch break, and I really need to get back my grading work, so I am going to very aggressively zoom in what I think are the main points. I will also not try to fully explain and answer everything, just on trying to make my position clear.
>
> No problem.
>
> > > ...Context...
>
> > Very interesting. Many thanks for that.
> >
> > > Proper Use of Paper
> >
> > Hard to be completely certain, but I think the answer is a very strong: No. Unless his project was to write a programming or query language for a similar data model and implementing the type inference mechanism in there. That seems unlikely from your description.
>
> Oh come on. I think I have explained it well enough. And you have not argued with the fact that it, and many papers like it, get used in the theoretical world that uses that model, and that model is implemented classically, in the OO/ORM world. I never said that it was a proper use technically it isn't, but the fact it in the physical universe (a) it if used for the model and (b) the model is implemented. Therefore there is a direct responsibility between the theoreticians who write those papers and the implementation of OO/ORM, the madness that we have to deal with. And (c) they don't give up that madness, because the theoreticians are writing more papers.
>
> If you are saying, you invented a small fold-up camping axe; someone used that axe to commit murder, yes, of course I agree. But it isn't that simple. You have written a paper on how to use that axe to circumvent forensics, the result being that many people are murdering many people, and the murder weapon cannot be found. Therefore, beyond inventing greatly-needed camping axes, to the extent that you subvert the [finding the] truth, you enable murderers. That is what I want to deal with.

[since this is the main point, I will focus on this]

I don't accept the premisse that OODBMs are necessarily evil, and disagree that they inherently break important engineering principles such separation of process and data, and the principle of real data independence. There were research prototypes which you have probably never heard of that got this reasonably right. But for reasons we can go into later all the commercial products broke these principes. Not that this played the biggest role in their lack of succes, but it did play a role.

I distinguish that from ORMs, which I consider an unhappy kludge, even if many practitioners seem very happy with it and defend it with both the same type of arguments (their practical experience, building real-world systems, having more experience with existing technology, etc.) and vigour that you are displaying here. In my own experience they can have their use, but can also cause great damage. In all cases, at the time that I wrote my paper it was far from clear that this would become a leading paradigm. It was certainly not what I had in mind. And there has actually been research, theoretical and practical, since then to allow easier acces to data sources, relational or not, from programming languages without the need for ORMs. Understanding type inference is actually a part of that.

> > > From reading your paper, I cannot say that he (or the OO/ORM crowd) is using it improperly
> >
> > "Improperly" does not even come close. :-)
>
> Agreed. Within the context explained previously, and above.
>
> But he already has, it is a done deal. I have to deal with that, because his use of the paper was not questioned. And in the context, I could not identify any improper use. (You have identified it to me now, but even that, does not deny the context.)

You cannot blame scientists for non-scientists misunderstanding and abusing their papers. It's simply not practical to try and make them fool-proof in that sense.

> So let us limit the issue discussed in your paper as it regards the model, only. It supports the model. The model is bankrupt. All my comments still apply (I went over them):
> - you SHOULD know that the model breaks the architectural principle

Let me stop you right there. As you know I do not agree with that, so if you want a meaningful exchange of ideas, we'll first need to establish this.

I have on my side all the relevant research communities, not just the more theoretical ones such as PODS, ICDT and DBPL, but also the more applied communities such as VLDB, SIGMOD, ICDE, EDBT, etc. I visit all of them regularly. I have organised workshops in some of them. Been in discussion panels. I meet there both theoreticians and experts on DBMS construction, many of them also working at commercial DBMS suppliers and working on actual DBMSs. Did I already mention that I actually have done some systems research myself on indexing and query optimisation? Hence my interest in these communities.

Pretty much all the researchers in these research communities disagree with that claim of yours. These are the leading experts in the world on these matters.

Not that I consider this a very strong argument. I don't. It is argument by authority, which should be avoided in real scientific discussions. But I hope it brings home the point that you will have to come up with something better then your personal practical experience as the only argument justifying that claim.

> > > - it acknowledges that there are myriad errors in the model
> > > ___ that data integrity (the tiny bit that you do understand) is broken
> >
> > No. It looks at how to reason over types and find inconsistencies in schema specifications. Something that happens in any reasonably expressive data modelling language where you can specify integrity constraints. That does not mean that such a language is broken.
>
> The opposite could be claimed: if your constraint language is so weak that it cannot express inconsistenties as studied here, it is probably too weak.
>
> Hang on. That is correct. My language (IDEF1X plus SQL, which exists, for over thirty years, and can be used for implementation), which you may consider primitive, compared to yours (which does not exist)
> - expresses all those things: consistencies; inconsistencies

IDEF1X by itself cannot, but that's actually fine given the purpose it was designed for. A stronger constraint language is not always a better thing.

> He is not using such papers within the theoretical exploration context, yes. But you cannot deny that such papers are used to validate and justify the classic OO/ORM model, and their implementations. All your mentors, Abiteboul, Hull, Vianu, et al, support the OO/ORM crowd, and do so openly. Just look at this pig poop in ch 3 "Relational Model" and ch 11/Translating to RM in the Alice book: those are serious attacks against the RM, and constructed on a fraudulent basis.

Yeah, I know you claim that. I don't see it that way, and with me all database researchesr, both theoretical and applied, that I know. So unless you are going to supply some real argument for this claim, this discussion is nog going to go forward.

> > > But first, I hope you don't mind me asking, please confirm that you can /read/ standard IDEF1X data models that we have been using since 1985, and UML classifiers. I am shocked to find out, as evidenced in the Normalisation thread, that many (all ?) theoreticians cannot do that, eg. they cannot read the predicates or the constraints that are in diagrammatic notation, and ask for them to be spelled out in text form.
> >
> > I don't think that's what they were doing,
>
> Well, they said the words:
> > > dependencies haven't been stated
> > > Assuming certain external predicates [ie. implying they have not been given]
> > > your drawing of boxes and lines

Indeed. The complaint was that it it was not clear if all relevant dependencies had been explicit in the diagram and/or the description, which is necessary for correct normalization, and as indeed you yourself indicated was not the case.

> > but yes, I can read IDEF11X and UML Class diagrams. Even taught them for a while to
>
> So you are clear on _not only_ the visual difference between:
> - solid and dashed lines
> - square and round corners
> but on the consequences, the ramifications, the consequences ? Ala the "expressiveness" in the non-existent theoretical languages, that exist in the primitive languages ?

Yes.

> And you will *not* /read/ anything in the model that is not in the model ? In the Address A model which does not have "candidate keys", you perceived such. Indeed, your intuition correctly picked up one of the *missing* constraints, due specifically to the *expressiveness*.

Not sure what expressiveness has to to do with this, but yes, when questions of normalization are considered in practice it must be thoroughly checked that all valid dependencies have been made explicit. Many incompetent data modellers tend to forget that.

> While I cover the OO side quite nicely (I dictate standards) and I lead teams (but we use 4GLs that generate objects, we do not actually write objects, same as we do not actually write SQL), I do not profess to be a specialist in UML notation. As you will know, since you are teaching it, it is not a standard by any stretch of the imagination, it cannot be used for verification of the completeness of the model, let alone verification of the model (both of which we can do in IDEF1X). Everyone adds and drops whatever they want. There is one symbol and it is used, misused, and abused, for everything. Most of the other symbols and notation is lost. Therefore, while I do draw UML diagrams (as distinct from erecting IDEF1X models), I am not a UML Notation specialist, I would ask that you forgive my mistakes.

No problem I'm not a big fan of UML for data modelling myself.

> The OO/ORM crowd make many mistakes. But if you ask me to name one, the most serious mistake, that has the most negative consequences, I would say, failure to observe the scientific and architectural principle of separation of Data vs Program.

The crowd that I'm in does not do that, so I'm not sure who you are talking about now.

• Jan Hidders