[comp.lang.c++] Code Reuse

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!marc