Re: Argument for 1NF by counter-example

"Tony Douglas" <tonyisyourpal_at_netscape.net> wrote in message news:bcb8c360.0410300543.69602fd3_at_posting.google.com...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message news:<eqGgd.23408$HA.19911_at_attbi_s01>...
>
> Hi Marshall,

Hey hey!

> > With such a powerful facility at the core, it's not clear to me
> > whether any *further* parametric polymorphism is necessary.
> > After all, pretty much 100% of the example uses of parametric
> > polymorphism are container classes. Do we need parametric
> > functions or modules if we have relations? Dunno.
>
> If I'm thinking of a programming language that happens to do
> relations, it's not totally evident to me that everything that I might
> want to write in that language would deal with relations. Apart from
> which, why throw something away ?

Well, it's not so much "throw away" as it is "don't add." Certainly the obvious reason not to add a general purpose parametric polymorphism facility is that it is hugely complex, and adds a lot to the cognitive burden of the user of the programming language.

I agree with you; not *everything* will be relations, but perhaps most things will. Will the part left over need PP?

> > I'm strongly against 3VL, but I have a slightly different take.
> > In my mind, "missing" information is different than any
> > of the other things that 3VL is usually used for, such as "N/A"
> > or what have you. I think of missing information as a cardinality
> > issue; the data is merely absent, as opposed to using a special
> > marker, such as one might use for N/A or NAN.
>
> Hmm. I'm not sure on this; I would probably tend to have an
> alternative in my data type definition which says the data is absent.
> Roy H knows someone who can come up with about 50 different
> interpretations for NULL, which could make for some very broad data
> definitions... ;)

See, the mere existence of those 50 null-like things argues in favor of having this kind of thing be application-specific. Whereas *missing* is not application-specific; it's part of the data model. Anyway, that's my current thinking.

> Indeed. I think there are possibilities here, but a lecturer friend of
> mine has had a long running undergrad dissertation proposal for adding
> some sort of type system to Prolog, and is becoming increasingly
> certain that types and Prolog don't really mix. Unfortunately, the
> order of evaluation comes out of the execution model for Prolog.
> Eventually we'd probably have to replace so many bits of Prolog that
> the Prolog-ness will probably go away too.

Food for thought.

> Thanks for the clarification. The time is coming when I'll have to buy
> a copy of TTM, I fear.

It's certainly worth reading, if only for the perspective. But as someone I know said, reading it was like hearing an axe grinding away in the background on every page.

> It may be a good thing that they disagree with each other if you like
> an empirical model of things (ie. "chuck some stuff at the wall and
> see what sticks") but it means you can't really have a general purpose
> object database; you could have a C++ object database, or a Smalltalk
> object database, but putting a Smalltalk object in a C++ database
> might end up with some interesting issues.

That's a fair point.

> > Furthermore, the specific semantics of each OO language are
> > quite well nailed down; there is little or no fuzziness in the
> > Java spec, or the C++ report, etc.
>
> Hmm ! When I see some denotational semantics for them, then I'll agree
> with you. For the moment, I'll restrict myself to "hm!" (Although
> there might be some operational semantics for Java out there. Anything
> involving C, as C++ does, is on shaky ground though.)

I doubt a denotational semantics would make sense for Java since it's intrinsictly multithreaded.

> > Why do we have to agree? Why can't we try out lots of different
> > ideas and see which ones work best?
>
> There has to be *some* sort of theoretical model behind all this; if
> there isn't then it's just experimentation in the vague hope of
> finding an answer. And if you're not sure what the answer is, how do
> you know when you've found it ?

But how are we to judge the theoretical models? I would say, by the same criteria as we judge the results: usefulness and soundness. There are many models that have these qualities, but that aren't mutually compatible.

> > > Also, the objects have, for
> > > me, a very particular application - modeling dynamic interacting
> > > processes. What does it mean to store one of these things in a
> > > database? If we're using them for, effectively, abstract data typing,
> > > then there are better, simpler, more conceptually robust answers than
> > > object orientation for that.
> >
> > As far as what makes a good abstract data type mechanism, I'd
> > say objects are it. They've pushed out every other way of
> > doing things, and with good reason.
>
> Think about most things in IT that have achieved dominance; have they
> done it for good reason ? And following on from the point you make
> below, why bother with objects in databases ? Are we doing anything
> with them that we couldn't do with abstract data types in Modula-2 or
> Ada ?

I did not say that all things that were dominant became so for good reasons. I specifically said *objects* are dominant and became so for good reasons.

> > As to the question of what it means to store an object in a database,
> > the only real question is what do you do about variables inside
> > objects, and pointers. And I don't think it's out of the question to
> > say that they just get flattened, and go away, subsumed by the
> > "variable-ness" of the database itself, in which case
> > the answer is very simple indeed.
> >
>
> Yes. They stop being objects and become ordinary, if complex, values.

Agreed.

Marshall Received on Mon Nov 08 2004 - 18:34:49 CET