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

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

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

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

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

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.

> 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

Marshall Received on Mon Apr 28 2003 - 07:58:17 CEST