Re: MV Keys (was: Key attributes with list values)

dawn wrote:
> Marshall Spight wrote:
>
> I might have said it that way, but the way I would typically say it is
> that the user knows what it means. From my perspective this is
> somewhat like the fact that the user knows what any of the data values
> mean, whether the value is a list or not, although there are times when
> a developer needs to know this too. There are a few times when working
> on tools for the environment when I wished the user told the system
> whether they cared about the ordering or not, but it is not a
> significant problem.

I agree that the magnitude of the problem probably isn't huge. But I can't help but wonder whether this is one of those problems when, once it's solved, even those people who were saying it wasn't a big deal will decided they could never go back.

As far as I know, there has never been a general purpose language with full support for the relational algebra. Once someone has that, what might their life be like?

> > Lists are just fantastically easy to implement and fantastically
> > easy to use,
>
> You rock, Marshall!

Yay me! :-)

> > and so they get used for things whether it makes
> > sense or not.
>
> Programmers, in general, tend to use what works.

And for the most part, what else are they going to use? Can you think of a general purpose language that has support for relations? Can you think of a general purpose language that *doesn't* have support for lists or arrays or some kind of native ordered collection?

There are a few languages floating around with some higher level collections. Python, Perl, Icon. They might have bit sets or char sets, or they might have maps. But once you have grokked relations, the idea of going back to even those collections is stultifying.

> > Further, it can
> > leak into the semantic level. Is this equation correct?
> > [a, b] != [b, a]. If you are using an ordered collection
> > to represent unordered data, you'll get the wrong answer.
>
> Yes, that would be the type of activity where a programmer would need
> to know the ordering requirements related to this particular list. The
> programs then document that fact with any such equality tests.

Right, and this is probably not very hard. But it would be even less hard if the system just did it for you.

> [I've
> heard that there are practitioners who refer to lists where the
> ordering is meaningful as "ordered lists" but that it bugs the crap out
> of those with more ivory tower leanings who insist that all lists are
> ordered ;-) ]

I can't tell you how thrilled I am to be called "ivory tower." I have only the lousy bachelor's degree, and I work with Ph.Ds all the time. Curse them and their knowing-a-lot-more-than-me brains! Ha!

> I love it! May I substitute relation instead? Then it reads
> "It's not that relations are difficult. It's just that lists are
> easier than they have any right to be."

Yeah, well, doesn't that sound just about exactly right?

But again, once you grok relations. Once you've done a five way hub-and-spoke join with two aggregates, a case statement, and a rollup, you'll never go back. In terms of bang-for-the-buck, nothing can compete with relational operators. Natural Join is a natural high baby.

Marshall Received on Mon Feb 27 2006 - 05:12:45 CET