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

Marshall Spight wrote:
> David Cressey wrote:
> >
> > The way Pick (and I presume most of the MV family) represent lists is
> > inherently ordered. And, whenever I ask Dawn, or any of the other Pickies
> > who dorp in form time to time whether the order in a list conveys
> > information or not, the answer is always the same:
> > "the programmer knows what the data means".

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.

> This error is endemic to computer programming. For example,
> most Java programmers in most contexts will use a java.util.List
> as storage for unordered collections. It is even in the stardard
> library that way.

Cool, I mean, what were they thinking!?

> Lists are just fantastically easy to implement and fantastically
> easy to use,

You rock, Marshall!

> and so they get used for things whether it makes
> sense or not.

Programmers, in general, tend to use what works.

> And when I point this out to most people,
> they ask "where's the harm?"
>
> The harm is the same as always comes from overspecifying.
> The system can only work with what it knows, and if you
> told it a collection was a list, it's going to studiously keep
> the elements in order, even though it doesn't need to.
> Opportunities for optimization are lost.

Understood. However, I would think there are some optimizations that can occur by keeping data as a list.

> 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. [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 ;-) ]

> A line I remember from years ago: "It's not that polar
> coordinates are difficult. It's just that rectangular
> coordinates are easier than they have any right
> to be."
>
> Substitute set and list and it still works. :-)

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

Cheers! --dawn Received on Mon Feb 27 2006 - 03:43:56 CET