From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,7f8fc37d854731d6 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public From: David N. Smith Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/11 Message-ID: <567h79$10l0@watnews1.watson.ibm.com>#1/1 X-Deja-AN: 195787210 distribution: world references: <32813322.41C6@kyebek3.kjist.ac.kr> <3280BA64.30F8@rase.com> <5672ok$vea@grimsel.zurich.ibm.com> content-type: text/plain; charset=ISO-8859-1 organization: IBM T J Watson Research Center mime-version: 1.0 newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai Date: 1996-11-11T00:00:00+00:00 List-Id: In article <3283BB94.2D82@concentric.net> Alan Lovejoy, alovejoy@concentric.net writes: >To me, the "design" of a program is a language-independent abstraction. Implementation >inheritance is a coding issue. It's about how to express the program in a programming >notation with the least amount of code duplication and/or the least amount of >code changes when requirements change. I try to stay out of 'design' discussions for a variety of reasons, partly because they often have little to do with Design, and partly because the design-it-and-throw-over-the-wall school of thought seems to have the same kinds of problems in computing as it has in other fields. Yet, here is Alan saying these things and somehow I can't resist commenting. :-) Many other fields have found that integrating design, engineering, and manufacturing (into an iterative process) leads to better products, cheaper products, and products that are easier to maintain. One doesn't end up with air-conditioners or exhaust manifolds on top of spark plugs, making a simple job into a half-day or more of work. For that matter, Alexander's patterns involve all parts of the job, from materials all the way to living in the building. A building is not just designed then dumped on some construction worker to figure out how to make fit on a lot and which materials to use. Computer languages differ greatly in how they express algorithms. One thinks differently in APL than in FORTRAN or Scheme, or in Smalltalk compared to C. C++ programmers seem to think quite differently than Smalltalk programmers, having lots of ideas like friend functions, type hierarchies, templates, and lots more stuff that I find incomprehensibly unnecessary and totally void of need or interest. My own biases aside, the point is simple: Programmers think differently in different languages. Even Java and C++, two peas in similar pods, foster different thinking patterns. I'm not interested in starting a language war. I'm a widely known Smalltalk bigot (or at least widely know as a Smalltalk bigot :-) and probably warped beyond any chance of a cure. But when I hear my friend Alan make such inflammatory statements, My fingers start to itch. I do not think one can separate design from 'mere' coding, no matter how grungy one thinks coding to be, nor how lofty one's ideas of Design. One designs a fiberglass body (and much of the rest of the car) very differently than a steel body. One designs a stone house in a totally different way than a frame house. One should design a Smalltalk program in a different way than a C++ program since there are fundamental differences in how the languages work and how people think in them when using them well. The design of a program should be an integral part of the design of the implementation of a program which should be an integral part of the coding of a program. This does not mean there is so separation between the parts. Car companies still have designers, design engineers, manufacturing engineers, and assemblers. These people with different points of view need to work together as partners, with the designer cognizant of enough of the details of the target language not to get in too much trouble, and the ultimate programmer cognizant of enough of the high-level design to understand where it all is going. Failing to consider the language at design time can leave issues open that need to be closed. If the designer has learned 'object design' but has never programmed an object, a condition I fear happens all to often, is the design suitable for implementation and maintenance in any language? Please note that I am not saying that it is impossible to implement designs thrown over the wall from a designer who doesn't consider language. I am suggesting that such designs can lead to very poor programs. Since programs are the ultimate product of the whole process, and it is the program that will be used, lived with, maintained, or thrown away, it is the program that matters, not the original design. To the extent that a programmer had to perform heroics to fit a design to a language, the design has failed and the resulting product is the poorer for it. Dave _____________________________________________ David N. Smith IBM T J Watson Research Center, Hawthorne, NY Mailto: dnsmith@watson.ibm.com Home Page: http://www.dnsmith.com/ _____________________________________________ Any opinions or recommendations are those of the author and not of his employer.