Re: Multiplicity, Change and MV

From: dawn <>
Date: 18 Apr 2006 06:46:18 -0700
Message-ID: <>

Bob Badour wrote:
> x wrote:
> > "dawn" <> wrote in message
> >
> >
> >>x wrote:
> >>
> >>>"dawn" <> wrote in message
> >>>
> >>>
> >>>>x wrote:
> >>>>
> >>>>>"B Faux" <> wrote in message
> >>>>>news:EvS_f.24004$
> >>>>>
> >
> >
> >>>I wonder if those who use them are confused by them or there are some
> >>>precise definitions of them.
> >>
> >>There are some terms with very precise definitions such as file,
> >>attribute/field, value (on my site in the MultiValue triology,
> >>particularly the Data "flashcards"), but since the model is not aligned
> >>precisely with any single, simple, mathematical model, there is a lot
> >>that is not nearly as precise as a mathematical definition would be.
> >>
> >>Most terms are trivially defined. When an MV person says or writes a
> >>term in English, the meaning is found in an English dictionary. There
> >>is not a big distinction between saying that "Courses have
> >>prerequisites" (conceptual data model) and the correspnoding "Within
> >>each Course we will place a list of Prerequisites" (act of defining a
> >>dictionary). It can be difficult to explain the difference between a
> >>conceptual data model and a logical data model to an MV person. If a
> >>file called Person has a field called FormerNames, that is the
> >>implementation of the conceptual model (coming from the "real world")
> >>where a person might have a list of former names.
> >
> > This might be the reason of programmers productivity.
> Human languages are imprecise -- often with multiple possible meanings.
> This leads to frequent misunderstandings, which humans have evolved to
> deal with in a reactionary manner. Human languages are much less
> susceptible to symbolic manipulation, reducing the opportunities to
> increase productivity through automation.
> I fail to see how such an imprecise language could increase
> productivity. Or are you suggesting that the programmers' productivity
> has been reduced as a result?
> >>Nothing in the application would break if you change the cardinality of
> >>an attribute (although it would be possible to write some code that
> >>would cause it to break, since you can do most anything).
> One should point out to Dawn that we established three years ago that
> her assertion above is patently false.

Please be more specific. What assertion is patently false and where is the proof of it?

> She is a willful ignorant
> interested in nothing more than self-promotion.

If I were, then I'd aim for better press than what this ng has yielded.

> >>>One RM rule say "no subversion" !
> >
> >
> >>There is most definitely a different sense of what is elegant between
> >>the two worlds. Pick defines elegance almost exclusively in terms of
> >>maintainable code over time that accomplishes what the business needs.
> We established three years ago that the meaning of Pick queries change
> subtly with no obvious indication to the user. The fact that Pick people
> believe this makes code mantainable suggests severe cognitive damage.

Having never programmed in the usual Pick language (DataBASIC), but having managed projects using a variety of approaches, I found that a dog-ugly (from an RM perspective) MV database (where my original response to it was "that's not a database!") seemed to cost less money over time. It was faster for developers to fix it, to enhance it, and to administer it. It definitely is not perfect. This was more disturbing to me before I researched it than it is now. It was really hard for me to accept that the product that was seemingly not based in any rigorous theory anecdotally (in my experience) provided the biggest bang for the buck for a company. So, I'm still searching for whether this really is true (it still seems to be, but I have no emperical data to prove it, just as the RM has no emperical data for just about claim it might make) and, if so, why, but I have collected some clues.

I am not, however, proposing that the industry move to Pick. I would suggest that if we want to get bigger-bang-for-the-buck software development, we might be able to learn from environments like Pick, MUMPS, and others not encumbered with the RM.

Take care. --dawn Received on Tue Apr 18 2006 - 15:46:18 CEST

Original text of this message