Re: Lucid statement of the MV vs RM position?

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1145916318.980049.203040_at_j33g2000cwa.googlegroups.com...
> David Cressey wrote:

> > The second question for me is how one distinguishes between a list used
as a
> > poor man's representation of a set, and a list used as a list, where
> > placement in the list is supposed to carry information.
>
> That's a good question and I think we have discussed this one before.

Yes we have discussed this one before.

> The only hints in the vanilla dictionary combined with the data is in
> the name, description, and values. Developers have complete control on
> whether they treat it as a list, a bag or a set and they do not
> advertise this anywhere other than the code.

That's a problem if you are building a database where data can be shared across databases, and where developers of different applications do not have access to each other's code.

>
> Many people add attributes to the dictionary, but even then I suspect
> that few have found a need to specify whether the attribute really
> should be ordered or not. I'm certain there can be misunderstandings,
> but I don't even have anecdotes of this lack of metadata causing
> significant problems for an organization.

>
> > Thus the question is whether the list "(onions, mushrooms)" conveys
the
> > same information or different information than the list "(mushrooms,
> > onions)".
>
> Because the system is so language based, this concern is much like a
> concern for any list that a person might give in a sentence. It is
> often clear whether the order was important or not. When it is not
> clear, ask someone. I realize this is a less than satisfying answer,
> but it is the situation.

A database isn't a substitute for e-mail or voice mail. It's a more formal, and more predictable way of sharing data. Lack of clarity that can quickly be resolved orally in a face to face dialogue can be disastrous in the kinds of environments where databases are relied upon.

>
> > The answer I keep getting from Pickies is (after I've stripped away the
> > veneer) seems to be: "It's all in the mind of the programmer! Isn't
that
> > wonderful!"
>
> The control of whether something implemented as a list is a list, bag,
> or set is addressed by developers, but the answer of which is in the
> mind of the end-users too.
>
> > My response is that it's not wonderful.
>
> I agree that it is not tight. I wish I could come up with any time
> this has botched things up.

Oh, come on! This has been botched up thousands of times in the pre database era, by people using FORTAN, COBOL, or what have you. If you never ran across any of those cases, I wonder why. If Pick is somehow ineffably different from classical programming languages, in a way that prevents this confusion, while still allowing things to be "loose", then I would think at least one practitioner of Pick would have been able to explain it to the rest of the world.
>
> > The whole reason I migrated from
> > files to databases was to get away from data whose description was
buried in
> > some other programmer's mind.
>
> I was happy to migrate from VSAM to IMS for the same reason. I don't
> know what you could have told me that would have made me think it was a
> good idea to use Pick. But having done so, it sure does seem to have
> some advantages that could help the industry for the future.
>
> > If you think that keeping the ultimate key to
> > decoding the data ought to be in the mind of the programmer, then I
think
> > you should stay away from databases. Either that or hang a suitable
warning
> > sign in front of any databases you have built.
>
> I really do understand why you say that. It is very frustrating that I
> have not yet been able to explain it.
>

Allow me to suggest, as gently and politely as I can, that your problems in explaining it have one root cause. You are unable to explain it, after years of trying, because it simply isn't true. Received on Tue Apr 25 2006 - 01:58:22 CEST