Re: Just one more anecdote

dawn wrote:
> Marshall Spight wrote:
> >
> > 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.
> >
> I'm thinking of only using set operations when putting things into and
> taking things out of my purse. After all, that approach is based on
> set theory and set theory rules! ;-)

These analogies between math and the physical world don't work for me. Do the operations of taking things in and out of your purse obey De Morgan's laws? How much physical space in your purse does the number 3 take up?

> > > 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.
>
> This is where we have a perspective problem. For purposes of this
> discussion, I will assume that my dbms product works well with data --
> I want it to work well with me (with my developer hat on).

That is what I was talking about: the interface. I was not talking about whether the dbms has bugs or not.

> There can
> be theories upon theories that are hidden from me, but those that
> affect the APIs I'll be using (that I think you are calling a language,
> perhaps?) are the ones I care about for preparation of both a logical
> data model and an implementation data specification.

Right.

> In my API, if I do an insert into an ordered list, I don't want to
> manipulate any positioning attribute, or ever see one in any schema --
> I simply want the insert function when applied to an ordered list, to
> perform an insert into that ordered list. This is so basic and yet I
> haven't seen a respectable API for this feature in any SQL-DBMS tools.
> I don't know if it exists in Dataphor, but I haven't seen it in any
> relational theory I've read.

Now you've moved back from set theory to SQL. (But anyway, I agree this is desirable behavior.)

> > > 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.
>
> and, again, I want it to work well with me when I'm working with a
> logical tree.

That's what I said.

> > 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'm good with that. You are thinking of the design of a language and
> I'm thinking of using that language. I want it done well too. I will
> suggest that you don't have to be a one trick pony. You could provide
> an api for collections that are not sets or sets that are not relations
> or not only relations. If you want to refashion them into sets behind
> the scenes, have at it.

'Kay. That's pretty much what I'm talking about.

> I think of it in terms of services (even before it was cool to do so)
> -- what does a software developer working with data (whether stored on
> disk, in memory, sent as a message, or input by a human) need to do and
> how can that language/api be as sweet as possible?

By having a solid theoretical foundation, and not just by being an ad hoc collection of stuff someone found useful. That way lies Perl.

> > 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.
>
> And is that your api, or is that your kernel?

It's the interface between the human and the computer. Call that an API or a language or whatever. It's what you program in.  

Marshall Received on Wed Aug 03 2005 - 20:34:44 CEST