Re: Just one more anecdote

Marshall Spight wrote:
> 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.

OK, now I'm confused. What is that we do when preparing a data model? We are making an analogy between math and the physical world, right? We are preparing a map between the real world and a mathematical model. We are making a "mathematical metaphor" for our problem space, right?

Now, we want to operate with our model, instead of with the physical world. The closer our model is, the more our operations with that model will similarly model the operations we had in the real world with the modeled objects. That's the idea of a model. If we build a model of a building with a door here, then we expect that door to open in the model. It might not because the model might not be close enough to the real thing.

I can model real world objects with sets, such as a purse. I can then interact with the model instead of the actual purse. The better the mathematical model at capturing what is needed, while leaving behind what is not (models should leave things out - they are not the real thing), the less surprised I will be when I interact with that model -- it will seem "like a purse" in its operations even if behind the scenes it is build of different material. But my interactions with it should not be such that I don't recognize the analogy to a purse.

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

OK, then we agree.

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

I moved from theory to SQL only because I couldn't find anything in the theory, so I looked to the practice and didn't find it there either. The combination of the two is what leads me to believe that such operations are outside of the RM and even counter to it. Is that incorrect?

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

OK, got it.
>
> > > 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.

good deal
>
> > 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 agree with the first statement. I don't understand the second. I have only a little bit of experience reading (and debugging) Perl -- is it or is it not designed well? I'm really disliking PHP -- it seems like a language that someone whipped out of their back pocket, but I digress.

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

I think (but am not certain) that I want some bigger building blocks from that small api. They can be pre-defined functions or whatever, but I don't want just the bare minimum of a theory -- I want a full-fledged api that does what I need done with minimal effort from me (not from the machine or the language). "It's all about me, Al Franken" cheers! --dawn

>
> Marshall
Received on Wed Aug 03 2005 - 22:13:32 CEST