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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: Eric Clayberg Subject: Re: OO, C++, and something much better! Date: 1997/01/27 Message-ID: <32ECEFC6.3E8E@parcplace.com>#1/1 X-Deja-AN: 212618073 references: <32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E987FC.1FF2@rase.com> <32EB78FB.3EE6@jmpstart.com> <32EB9BCA.3013@rase.com> content-type: text/plain; charset=us-ascii organization: ParcPlace-Digitalk, Inc. mime-version: 1.0 reply-to: clayberg@parcplace.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (Win95; U) Date: 1997-01-27T00: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. 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. You can spend lots of time optimizing something up front that in the final analysis would have very little impact on your program to begin with. In fact, premature optimization can often lead to inflexible, even brittle, designs that will cause major maintenance headaches down the road. IMO, it's much better to get the program right first, and then optimize any areas that are actually affecting performance. Every optimization employed usually has a cost and that cost is felt in terms of reduced flexibility and loss of genericity. > Although it is of course possible to develop large and reliable systems > in Smalltalk Absolutely. I have seen thousands of them in operation and have worked on several dozen myself. > Smalltalk tends to unduly encourage premature coding. Smalltalk encourages getting the job done sooner rather than later. In many industries, time-to-market is one of the most important considerations. 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... -Eric