davidm@uunet.UU.NET (David S. Masterson) (02/17/90)
In article <136@dumbcat.UUCP> marc@dumbcat.UUCP (Marco S Hyman) writes: In article <CIMSHOP!DAVIDM.90Feb12100359@uunet.UU.NET> [I] write: Instead of a design model to follow, the approach seems to be more of "do what seems right programmatically" and the design will take care of itself. You start out trying to follow the right principles but end up satisfying the customer. That is, when the ultimate goal is to ``finish the damn thing and make it work'' you tend to do ``what seems right programmatically.'' A quote I stole from Jon Krueger (forgive me, Jon :-) in comp.databases who borrowed it from Knuth: Knuth (loosely): more evil has been done in the name of performance than any other area. My message meant to suggest that this seems to be programmers' attitudes to developing an "object-oriented" system, not that programmers were being forced into this mode by (forgive me) "real-world" constraints. The attitude that Marco expresses is a valid one for the programmer on the line, but, when talking about models for inheritance and composition, its too early. In a previous article, Dag Bruck pointed out the differences in the "American" and "European" attitude to code reuse. One of Bjarne Stroustrup's original goals for C++ was to reverse the trend of 80% new code and 20% old code for new projects. This would mean heavy code reuse, yet there appears to be no more facilities for code reuse in C++ then there would be in C except in the definition of the model that C++ follows. The problem is seems to be that this model is either not clearly defined or clearly understood or both. -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"
budd@mist.cs.orst.edu (Tim Budd) (02/20/90)
In article <CIMSHOP!DAVIDM.90Feb16140634@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >A quote I stole from Jon Krueger (forgive me, Jon :-) in comp.databases who >borrowed it from Knuth: > > Knuth (loosely): more evil has been done in the name of > performance than any other area. > In the interests of factual accuracy, let me point out that the quote should be attributed to Bill Wulf, not Don Knuth. Here it is: ``More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity'' in W. A. Wulf, ``A Case Against the GOTO'', Proceedings of the 25th National ACM Conference, August 1972, pp 791-97. Has been reprinted many times, for example in ``Classics in Software Engineering'', edited by Ed Yourdon, published by Yourdon press. --tim budd, budd@cs.orst.edu
marc@dumbcat.UUCP (Marco S Hyman) (02/21/90)
In article <CIMSHOP!DAVIDM.90Feb16140634@uunet.UU.NET>
cimshop!davidm@uunet.UU.NET (David S. Masterson) commented on something I
said regarding design models
You start out trying to follow the right principles but end up
satisfying the customer. That is, when the ultimate goal is to
``finish the damn thing and make it work'' you tend to do ``what
seems right programmatically.''
with a (version) of the Bill Wulf quote
``More computing sins are committed in the name of efficiency
(without necessarily achieving it) than for any other single reason -
including blind stupidity''
cimshop!davidm@uunet.UU.NET (David S. Masterson) continued with
My message meant to suggest that this seems to be programmers'
attitudes to developing an "object-oriented" system, not that
programmers were being forced into this mode by (forgive me)
"real-world" constraints. The attitude that Marco expresses
is a valid one for the programmer on the line, but, when
talking about models for inheritance and composition, its too
early.
While I enjoyed the Bill Wulf quote I don't see how it is applicable to
my comments unless ``efficiency'' is the efficiency of getting a
product/project done and out the door. Also, it's never to early to think
about the ``real-world.'' It is my contention that a design
is not finished until the product ships -- if then. Requirements, design
and implementation are recursive tasks. All two often a customer will come
up with a new, last minute requirement that necessitates a change to the
design. When this occurs the design model used is ``how can I make this
change with minimum impact on schedule and budget.'' The last concern is
``does this change fit the inheritance model or the composition model.''
Extensible designs are less likely to break under the weight of
last minute requirements changes. OO concepts, especially much aligned
inheritance, tend to make designs extensible (with practice). Successful
designs will tend to be re-used. In an OO environment design re-use leads
to code re-use. (Ain't encapsulation, classes, and abstract data types grand.)
This all takes time, though. Look at a programmer playing with Smalltalk
for the first time. The ones I've seen (including myself) started looking
at ``code'' using the browser and then then tried to write some ``code''
of their own. The idea of growing an application by making incremental
changes to the existing classes doesn't come until the the programmer
becomes familiar with the existing classes. In the case of languages like
C++ code re-use wont come until the the second or third project the
programmer is on. It will take that many tries just to come up with code
worth re-using.
I'm off my soap-box.
--
// marc {ames,pyramid,sun}!pacbell!dumbcat!marcdavidm@uunet.UU.NET (David S. Masterson) (02/23/90)
In article <138@dumbcat.UUCP> marc@dumbcat.UUCP (Marco S Hyman) writes:
[...comments on my comments about his comments...]
[.... ??? ^^^^ is that recursive ^^^^ :^) ....]
While I enjoyed the Bill Wulf quote I don't see how it is applicable to my
comments unless ``efficiency'' is the efficiency of getting a
product/project done and out the door.
Exactly.
Also, it's never to early to think
about the ``real-world.'' It is my contention that a design is not
finished until the product ships -- if then. Requirements, design and
implementation are recursive tasks. All two often a customer will come up
with a new, last minute requirement that necessitates a change to the
design. When this occurs the design model used is ``how can I make this
change with minimum impact on schedule and budget.'' The last concern is
``does this change fit the inheritance model or the composition model.''
I agree. This is where the "programmer on the line" makes his money. That
is, he has to understand and balance the constraints of time and money with
what he might feel is the more "theoretical" right thing to do. The
question/point I'm driving toward is not what that "programmer on the line"
must theoretically sacrifice in order to "get the job done", but more of what
the model is that he would start with in his evaluation of the project
(namely, the OO model). My contention is that the design model that you are
expressing above is not an Object-Oriented model, but more of a "produce by
whatever means" model.
Extensible designs are less likely to break under the weight of last minute
requirements changes. OO concepts, especially much aligned inheritance,
tend to make designs extensible (with practice). Successful designs will
tend to be re-used. In an OO environment design re-use leads to code
re-use. (Ain't encapsulation, classes, and abstract data types grand.)
The questions here are:
1. What was the object-oriented model you began with in your design and why?
2. What did practice teach you was wrong with that model?
3. What is the definition of "re-use"?
This all takes time, though.
True, as it is true with any other modelling system. However, an
understandable and complete model helps to cut down this time. The producer
of a product is far too worried about "getting it done" to be worried about
using a design model that doesn't answer all his questions about the project.
From what I've seen (and, admittedly, I'm no expert), the OO model for problem
solving seems somewhat haphazard in its application because of incompleteness
in people's "working" definition of what it is. This can be disconcerting to
the "programmer on the line" who has to apply OO to his product because its
the new industry buzzword (which seems to be a big reason for its use) and not
because understands why it should be used.
I'm off my soap-box.
Me too, but soap-boxes are such fun objects to play with... 8^)
--
===================================================================
David Masterson Consilium, Inc.
uunet!cimshop!davidm Mt. View, CA 94043
===================================================================
"If someone thinks they know what I said, then I didn't say it!"