Re: Do Data Models Need to built on a Mathematical Concept?

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:Zp3ra.650860$F1.86675_at_sccrnsc04...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:b8hm0t$2h7s$1_at_gazette.almaden.ibm.com...
> > "Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message
> > news:e9d83568.0304271138.63409dde_at_posting.google.com...
> >
> > Beats me. I didn't even have a relational databases course on my CS
degree.
> > OK, so it was cancelled that year, but it no-one seemed particularly put
out
> > about it and I knew no better at the time (I think I had the impression
that
> > they were old hat, industry things only, and this newfangled OO thing
would
> > replace them..!!!!)
>
> Ha ha! At my university, I had the opportunity to take database classes
> from Michael Stonebreaker, but I figured it would be about the same
> thing as taking accounting.

You were probably right.
Taken by Michael Stonebreaker, I guess it would be all implementation details and little theory?
The class I missed is taken by Hugh Darwen would you believe.

> > > I tend to agree with Marshall here that there is still room for
> > > an imperative component, both inside the implementations of the
> > > datatypes and their operators and outside and around the relations.
> >
> > From what I understand of type theory, you would defiantly want to go the
> > functional route for user defined type implementations.
>
> ("defiantly" of "definitely?" Not that I am opposed to doing things
defiantly.)

Ha. I guess I meant the latter, but either are OK ;-)

> Could you expand on that? It seems to me that the core of what I get out
> of TTM as far as UDTs goes is the clear definition of values and variables.
> I don't see anything particularly wrong with having variables. It seems to
> me the problems come when you allow variables to contain other variables.
> (That is, objects, pointers, etc.) As long as all a variable can do is hold
> a value, and variables can't be aliased, you are side-effect free. And
> THAT I think is the real issue: ridding ourselves of side effects, and not
> functional vs. imperative. (The functional guys just come out looking
> better today because they've managed to free themselves from side effects.
> But I'd say they did it the hard way.)

I'm no expert on FP, but I agree that side-effects are the real issue. (In relational also. Why do folks not see referential actions (and view updates!) for what they are - side effect changes to the database value)

Functional programs are at a higher level of abstraction. To quote http://www.haskell.org/aboutHaskell.html

    "The focus is on what is to be computed, not how it should be computed"

What, not How. Now where have I heard that before...

> > Show me a (useful) algorithm that cannot be performed in a relational
algebra
> > (hypothetically extended with 'features' from the FP world).
> > Why have two languages if we can get away with one?
>
> Well, we certainly *can't* get away with one. There are application
languages
> and there are systems languages. Take Java and C++ today, for example. Sure,
> they're deeply flawed, but they both have some cool things in them, and
they're
> the two most popular languages today. One is an application language; the
> other is a systems language. I'd certainly hate to use either for the
other's purpose,
> although it can be done.

Systems languages? That's almost like including 'hardware logic' in our definition of what is needed to build applications. Systems/internals is 'under the covers', use what language you like, it's outside of my world view.

> This language I'm semi-seriously designing, is an imperative relational
language.
> It's great for writing applications. It'd suck to write a device driver in,
in a manner
> similar to how much it would suck to write a device driver in Java.
>
> And besides that, why not allow one language to be embedded in another?
> I'd claim that's what regular expressions are: a special purpose
sublanguage.

Maybe we need a 'hierarchy' of languages, each one made more powerful that the previous by the addition of extra 'features'. The simpler ones are limited, but can be proved to terminate and are easy to optimise, the higher ones are more powerful but harder to reason about. The trick of coding then becomes to use the simplest language sensible for the problem at hand.

> > BTW does anyone have a good defn of 'imperative'. In the footnotes of the
> > TTM, Date (and it would be him) says:
> >
> > "we have recently observed a distressing tendency to confuse
procedural
> > with imperative ... In particular, D - or its relational portion, at any
> > rate - is imperative but not procedural"
>
> I always figured they meant the same thing. FOLDOC calls them synonyms:
>
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?imperative
>

Hum, we appear to be at a lose on this one.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon Apr 28 2003 - 19:45:51 CEST