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: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: Antoine Trux Subject: Re: OO, C++, and something much better! Date: 1997/01/28 Message-ID: <32EDB846.1398@research.nokia.com>#1/1 X-Deja-AN: 212704997 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> content-type: text/plain; charset=us-ascii organization: Nokia Research Center mime-version: 1.0 reply-to: trux@research.nokia.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.0Gold (Win95; I) Date: 1997-01-28T00:00:00+00:00 List-Id: Eric Clayberg wrote: > > 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. I would like to point out that the current Smalltalk implementations, which use dynamic compilation techniques, are very efficient. However, it seems difficult to have persons who have not recently used Smalltalk believe this, especially the ones who have a strong background in computer science! The only efficient way I have found so far to convince those persons is to show them some of the demos included in GF/ST (a framework for building Smalltalk applications with graphs). Now, although most current Smalltalk implementations are more than fast enough for most of the purposes, it is true that the code produced is not quite as fast as C code. Sometimes (perhaps once a month, once a year, or never, depending on what kind of applications you write), you just have to take the most of every CPU cycle. But even in those cases, you can usually isolate the time-critical routines, code them in C(++) or assembler, and call them from Smalltalk. This is possible at least in the Windows platforms with the major Smalltalk dialects. This being said, I fully agree with what Eric writes. Antoine Trux