On May 7, 11:53 am, David Segall <da...@[EMAIL PROTECTED]
> wrote:
> Lew <l...@[EMAIL PROTECTED]
> wrote:
> >Lew <l...@[EMAIL PROTECTED]
> wrote:
> >>> Studies and experience have consistently shown that
> >>> there is more than one "correct" solution for almost every software
> >>> requirement. The history of computing has notably omitted attempts
to find
> >>> any "true correct" data model or user interface, and has focused
instead on
> >>> elucidating principles by which *a* correct solution can be found in
any given
> >>> situation.
>
> >David Segall wrote:
> >> I believe that the relational database,
>
> >Never yet implemented, not implemented in the same way by all vendors,
and by
> >no means the only database model in production use.
>
> >> the spreadsheet,
>
> >of which many varieties exist, and remains to this day only one kind of
> >do***ent or analytical tool, competing with and usually giving way to
> >presentation software and database systems.
>
> >> the Xerox [Palo] Alto user interface,
>
> >Tweaked, altered and re-interpreted a zillion ways by a zillion
vendors. Open
> >Look is not Mac is not Motif is not any of the dissimilar Windows
interfaces.
> > A mouse is not a pen on a tablet is not a trackball is not a
> >retinal-tracking device. The WIMP interface is one of many, and not
the only
> >one in production use; command line remains strong and will never go
away.
>
> >> the Java-style virtual machine,
>
> >A subject of huge controversy, as evidenced by the vehement C++ vs.
C#/Java
> >religious wars. Not a clear winner; certainly not the one "true,
correct"
> >execution model.
>
> >> models was so intuitively right that they persisted despite the fact
>
> >... that to this day many viable alternatives exist and remain
competitive
> >with these so called "true, correct" ways.
>
> >> that many of the early implementations were unacceptable. Of course,
> >> those historical milestones do not contradict your second sentence.
>
> >Nor the first. Every single example you cited is one of several
solutions to
> >a given problem, e.g., issuing commands to the computer. In each case,
the
> >alternative solutions are more viable for certain scenarios, and remain
> >popular to this day. Every single one is realized differently by
different
> >vendors. None of them are likely to remain the best practice for the
> >foreseeable future. Each and every example you cited sup****ts the
thesis that
> >there has yet to be found any one "true, correct" solution in software
> >engineering.
>
> We seem to have an irreconcilable disagreement that is based on
> different views of "true and correct". I think that chocolate cake is
> an im****tant concept that we all share. You argue that real chocolate
> cake does not exist because nobody has produced a cake that is
> entirely chocolate and/or that there are zillions of different recipes
> for chocolate cake and/or that there are sound reasons for not eating
> chocolate cake. I can't refute any of those arguments. My view is that
> the chocolate cake model is "true and correct" because everyone who
> reads the desert menu knows what chocolate cake should be and because
> chocolate cake has become an im****tant part of the menu.
>
> It seems that you agree that we have a common understanding of a
> "relational database" or the "Alto user interface" because you can
> argue about them. I assume that you would also agree that both have
> had a profound effect on the history of computing. Our disagreement is
> therefore only whether those terms describe real, singular, intuitive
> models. I think they do. I believe, based on Ed's first use of the
> term, that I can use "true and correct" to describe that.
Let's see. I used the term like this:
quote
There is no ONE TRUE CORRECT SOLUTION.
It is a matter of balancing features (performance, data storage, code
size, code functionality).
quote/
I think I would agree with Lew that the phrase "true and correct" is
an abstraction that does not exists in real-world products, including
software products. Precisely because there is that multidimensional
trade off, you only ever get to a local maximum because there is no
optimal solution for all cases. A product may be a significant
advancement in software development and still be nowhere near a "true
and correct" solution.
There is no one solution. So before you consider designing the DB, you
have to examine your requirements. And your requirements will differ
from someone else's requirements so that your final solution becomes
useless to them.
So ignore the goal of a perfect product. If you are designing a PIM,
just follow some reasonable development process and get it done. Maybe
when you finish you will realize you could have done it better. Good,
that means you are learning. But if you seek the perfect PIM at the
start, you will never complete it. The perfect, true, and correct PIM
cannot exist. (and in the general case, you can replace PIM with about
any non-trivial software product in that sentence.)
Ed
|
