Path: utzoo!attcan!uunet!husc6!rutgers!aramis.rutgers.edu!webber From: webber@aramis.rutgers.edu (Bob Webber) Newsgroups: comp.misc Subject: Re: Basics of Program Design Message-ID: Date: 23 Jul 88 05:03:33 GMT References: <901@td2cad.intel.com> <3061@rpp386.UUCP> <395@proxftl.UUCP> <505@proxftl.UUCP> Distribution: na Organization: Rutgers Univ., New Brunswick, N.J. Lines: 79 In article <505@proxftl.UUCP>, bill@proxftl.UUCP (T. William Wells) writes: < A minor grouse: why complain about the IBM-PC and its supposed < limiting effect? Especially since a good part of the design of C < caters to the characteristics of the PDP-11, a machine with < characteristics similar to the IBM-PC but much more restrictive. You will be amused to know that I agree with you that C is PDP-11 biased, but that it turns out to be a minority opinion vigorously denied by at least one of the inventors of C. <... < You know, I just finished writing a data compression program. < That was over 3000 lines of code, better than half recursive < routines. I, at least, know when to use recursion. And when and < why to avoid it. I hardly see how the above allows you to deduce that you know when to use recursion and when to avoid it. I too have written many lines of both recursive and non-recursive code -- so the same line of reasoning would say that I too know when to use it and when to avoid it. Indeed, more to the point, I have written a few (not just one) of these student compiler projects that the original example was taken from. <... < Sigh. Don't you read carefully? I did NOT say to optimize < strlen to death. I said to do the best job you can. That Yes I read carefully. ``The best job you can'' is a wonderfully ambiguous phrase comparable to ``do it right.'' It has no meaning outside of the context of the rest of the message. <... < The original point was the rather elementary fact that a < recursive strlen is a bad idea, sufficiently bad that thinking of < a recursive strlen algorithm as being good is idiotic. Just wait This is not an ``elementary fact'' -- it is sheer opinion. < till you use said strlen on a machine with a few K of available < stack space and you try a strlen on a long string. Boom. Boom? I thought the IBM-PC only did that when you messed around with the graphics card. < Your reply is likely to be something of the order: why limit < programmers to today's technology? And if that is so, we have < nothing further to discuss. Why is it that people always come to conclusions like this at the end of a long message? < < to run on an operating system that routinely crashes (such as UNIX) < < or a chip as badly built as the 8086-family (what on earth were they < < thinking about when they set up pointers -- surfing?)? The world does < ^^^^^^^ < Perhaps you are ignorant of history? They were thinking of < COST. Considering how much it has COST everyone else, they must have had alot to think about then. < Perhaps *your* UNIX routinely crashes, perhaps your compiler, < editor, and other tools fail too often; but attitudes such as < yours are the cause for your complaints. Actually, I suspect that the people who wrote ``my'' UNIX, compiler, etc., are much more likely to agree with your view of programming. < I have had enough of this discussion. I am not going to waste < further time with someone whose position is so far removed from < mine that he believes that, in C, a recursive strlen is as good < as a nonrecursive one. This is hardly my position -- my position is that I believe that for a student compiler project (particularly in the early stages of development), a recursive strlen is BETTER than a nonrecursive one, regardless of the programming language being used. --- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)