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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,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/13 Message-ID: <320fe7f4.7066811@nntp.ix.netcom.com> X-Deja-AN: 173823250 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> <320f14e5.213196860@nntp.ix.netcom.com> <01bb8854$c2f6b880$87ee6fce@timpent.airshields.com> organization: Netcom x-netcom-date: Mon Aug 12 9:42:24 PM CDT 1996 newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-12T21:42:24-05:00 List-Id: "Tim Behrendsen" wrote: > Mike Rubenstein wrote in article > <320f14e5.213196860@nntp.ix.netcom.com>... > > "Tim Behrendsen" wrote: > > > Mike Rubenstein wrote in article > > > <320bf032.7193774@nntp.ix.netcom.com>... > > > > > > 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. > > Either solution is perfectly clear to me, and perhaps you > could share the secret of a mistake free life, since you appear > to not be able to forgive my one type? I certainly don't claim to be mistake free -- that's why I don't change clear working code without reason. > > > 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. > > As I said, I would not go back and change working code > unless there was a good reason. If I was implementing it > the first time, I would do it efficiently the first time. But you did go back and change it. > > > 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. > > Because I was making a point about recursion, not about GCD > implementations. If the point was that assembly language knowledge helps, I'm afraid you blew it. > > > > 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. > > "Techniques are appropriate" That's the issue, isn't it? I would > say that anybody who implements factorial in C using recursion > qualifies as a bonehead and should have their programming license > revoked. > > > Assembly language is not needed to understand > > algorityms or efficiency. > > It's not a question of whether it's needed or not. It's a > question of what's best, and what we're doing now is certainly > not working. The level of incompetence that I see coming > out of CS schools is astounding to me. > > I've asked this before; why do EE graduates seem so much > better prepared than CS graduates? I think it's because they > start with the low level and work they their way up. > > > 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. > > So who's arguing that assembly should be used in production > any more? You have the benefit of all that background, yet > you argue that it's useless. I think that it benefits you more > than you realize. Or you less than you realize. I, at least, would not have changed Peter's code unless there was a specific reason. That is one lesson assembly language code has taught me. I've probably been helped more by my knowledge of about 25 higer level languages. Obviously, all other things being equal, it is better to know assembly language that to not know it. But all other things are seldom equal. I suspect that most beginning programmers would gain much more from learning some different HLLs. Given a choice, I'd strongly recommend one learn LISP, APL, Icon, or any of a few dozen other languages to learning assembly language. Michael M Rubenstein