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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: OO, C++, and something much better! Date: 1997/01/29 Message-ID: #1/1 X-Deja-AN: 213008450 references: <32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E987FC.1FF2@rase.com> <32EB78FB.3EE6@jmpstart.com> <32EB9BCA.3013@rase.com> <32ECEFC6.3E8E@parcplace.com> organization: New York University newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-29T00:00:00+00:00 List-Id: Robert Dewar wrote: > The idea that you can completely ignore efficiency and then somehow > fix it up later by "optimization" is appealing, but naive. if you want > efficient, you have think about this requirement from the start. To say > that you can deal with this later is very similar to the claim that you > can develop in a sloppy hack-away-and-get-it-working mode and then build > in reliability later. Eric replied "Not true at all. Getting the program "right" and the algorithms correct is the most important thing to do first. Premature optimization often leads to less than optimal results." Robert replies Well it depends what you mean by correct here. If correctness includes the notion of efficiency in an algorithmic sense (e.g. choose linear algorithms over quadratic algorithms where appropriate), then you are in fact agreeing with me, since the most important element in creating efficient programs is the right choice of data structures and algorithms. When I talk about worrying about efficiency up front, that is what I am talking about, not about replacing exponentiation by multiplication (an activity better left to intelligent compilers in any case). What does not work at all is to program something in a sloppy manner without regard to space and time use in choice of algorithms and data structures, and then expect to be able to "fix" the inevitable efficiency problems that result from these bad decisions. Such fixes may require complete rewrites, and in your time-to-market environment, such rewrites tend to be impractical. Eric said "Smalltalk encourages getting the job done sooner rather than later. In many industries, time-to-market is one of the most important considerations." Robert replies Sure and the world is obviously full of situations in which time-to-market is more important than reliability (almost the entire world of PC applications falls into this category, people are pretty much resigned to expecting PC tools to be unreliable). Eric said "Starting (and finishing) sooner and "large and reliable systems" are *not* mutually exclusive propositions. If you think they are, then maybe you are simply using the wrong tools..." Robert replies Certainly that is the case. However, in high reliability systems, take safety critical systems as an ultimate example, the coding time is a trivial part of the cost of a system in any case. By the way, are you aware of any safety critical systems written in Smalltalk? There must be some, but I don't know of any.