Re: Multiplicity, Change and MV
Date: Tue, 18 Apr 2006 13:21:14 GMT
Message-ID: <eJ51g.61664$VV4.1151927_at_ursa-nb00s0.nbnet.nb.ca>
x wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1145292548.823950.44180_at_u72g2000cwu.googlegroups.com...
>
>>x wrote:
>>
>>>"dawn" <dawnwolthuis_at_gmail.com> wrote in message
>>>news:1144858576.001309.90750_at_z34g2000cwc.googlegroups.com...
>>>
>>>>x wrote:
>>>>
>>>>>"B Faux" <nospam_at_nospam.net> wrote in message
>>>>>news:EvS_f.24004$NS6.8332_at_newssvr30.news.prodigy.com...
>>>>>
> >
>>>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. She is a willful ignorant interested in nothing more than self-promotion.
>>>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. Received on Tue Apr 18 2006 - 15:21:14 CEST