Re: Just one more anecdote

dawn wrote:
> Marshall Spight wrote:
> >
> > I hate to get all Fabian-Pascally on you, but the thing about this
> > is that the RM is based on set theory.
> >
> > I believe that you have identified quite a number of significant
> > deficiencies in *SQL*, among them 3VL, lack of change management
> > features, lack of support for ordered data, etc. I am fully
> > subscribed to the idea that these problems can and should be fixed.
> >
> > At the same time, I *don't* believe that you've made even a chip
> > in the giant granite edifice that is set theory, aka the RM.
>
> I have no intent whatsoever to discount set theory. I'm pretty sure
> (not certain) that I don't want my entire API to a database to be in
> terms of sets.

I suspect that's simply because you/SQL/the world hasn't figured out how to tap into the full power of set theory yet.

> Are you sure that
> you don't want a dbms product to do ordered lists,

I'm sure I want my dbms product to be able to work well with that particular type of set that is an ordered list.

> to give you an api
> for handing you a nodelist from a tree,

I'm also sure I want my dbms product to be able to work well with that particular type of set that is a tree.

> to have a better built-in
> understanding of a mapping, etc?

And I'm sure I want my dbms product to be able to work well with that particular type of set that is a map, or a function.

I also want all of these things to be able to work together in a seamless, elegant, and yes, beautiful way. The only hope I know of for this happening is taking the set theory idea and turning it to eleven.

If all I wanted to do was hack together a bunch of ad hoc functionality for all of the things you or I could enumerate, I could certainly do it with a big honking API library. The Java collections API does a pretty good job. But I want more.

> ... I don't think the RM is bad as a theory -- it is
> using it as the exclusive means of working with databases and data
> modeling where I'm not happy with it. Fair enough? --dawn

I hear you, but I'm not there. Set theory is *foundational*, and it's important in language design to have a solid foundation. Again, I don't want a bunch of thrown-together ad hoc techinques that happens to be the union of everything I happen to have thought of when I designed the language, extended again and again as I thought of new things. I have plenty of approaches to do that today; all I have to do is write out tens of thousands of lines of procedural code in my application and I can have it all!

I want something better. I want some *small* *simple* yet also *complete*
core that will do all of these things using a set of operations that's so small that it looks ridiculous when you first look at it. But still it provably does it all.

Not that this is an ambitious goal or anything. :-)

Marshall Received on Wed Aug 03 2005 - 06:42:37 CEST