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,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public From: miker3@ix.netcom.com (Mike Rubenstein) Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/12 Message-ID: <320f14e5.213196860@nntp.ix.netcom.com>#1/1 X-Deja-AN: 173676667 references: <31FBC584.4188@ivic.qc.ca> <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com> <4u89c4$p7p@solutions.solon.com> <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> <4uah1k$b2o@solutions.solon.com> <01bb853b$ca4c8e00$87ee6fce@timpent.airshields.com> <320b35a2.43769707@nntp.ix.netcom.com> <01bb8609$59339140$87ee6fce@timpent.airshields.com> <320bf032.7193774@nntp.ix.netcom.com> <01bb8802$a5ff3a60$32ee6fce@timhome2> organization: Netcom x-netcom-date: Mon Aug 12 6:44:45 AM CDT 1996 newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-12T06:44:45-05:00 List-Id: "Tim Behrendsen" wrote: > Mike Rubenstein wrote in article > <320bf032.7193774@nntp.ix.netcom.com>... > > "Tim Behrendsen" wrote: > > > Mike Rubenstein wrote in article > > > <320b35a2.43769707@nntp.ix.netcom.com>... > > > > Perhaps because you think like an assembly language programmer -- > > there's an enormous advantage to clear code. Efficiency may, or may > > not be important. Yet you assumed that it was worthwhile to make > > Peter's code more efficient. This is the assembly language > > programmer's disease. > > No, this is experienced programmer's disease. It's not as if > I go around optimizing everything, I just do it automatically. > When you train yourself to think about efficiency, you naturally > do it the efficient way the *first time*. The cumulative effect > of this is fast programs, and it doesn't cost any more effort. I see. Experienced programmers automatically optimize slightly inefficient, clear code to incorrect unclear code? Guess I'll have to remain a novice. Perhaps you need to get some new experiences. Changing correct clear code when there is no specific requirement is an assembly programmer's, not an experienced programmer's disease. Yes, I know that was just a typo (or several typos). But that happens. Only an assembly language programmer (and, frankly, not a very good one) would assume that efficiency was so important that clear code had to be changed and risk the problems. > > > If I were doing a lot of gcd calculations, I'd certainly try to > > optimize the program. But in most applications very little of the > > code is time critical. Where it is not, clear code wins over > > efficient code. > > Yes, I agree. Personally, they both seem equally clear to me, > but I could see how someone may prefer the recursive solution. > It is certainly the more "beautiful" of the two. So, why did you change it when there was no clear requirement for better efficiency? Even if one does not prefer that solution, it certainly was clear enough and correct. > > Furthermore, when teaching algorithms Peter's code is what you want, > > at least for the first cut. It shows a general technique of algorithm > > design, reducing a problem to a similar but easier one, that your > > code, even if written correctly, hides. > > I'm not sure if that's good or not. One of the famous ways to > show recursion is a factorial computation. Does that mean we > actually *want* people to implement factorial that way? In scheme (and some other languages) it certainly is the way to implement it. But that's not the point. If one understands the algorithm, one can code it using whatever techniques are appropriate. Recursion is not something to be avoided at all costs even in implmeentations where it is not efficient. Assembly language is not needed to understand algorityms or efficiency. For the record, I have extensive assembly language experience on IBM 360/370, 8080, Z80, and 80x86 and a little on IBM709x, Univac 110x, GE 425, Honeywell 6000, and DEC PDP 6/10. I've outgrown it. Michael M Rubenstein