Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!bloom-beacon!gatech!uflorida!novavax!proxftl!bill From: bill@proxftl.UUCP (T. William Wells) Newsgroups: comp.misc Subject: Re: Basics of Program Design Message-ID: <505@proxftl.UUCP> Date: 20 Jul 88 15:44:33 GMT References: <901@td2cad.intel.com> <3061@rpp386.UUCP> <395@proxftl.UUCP> <53374@ti-csl.CSNET> <464@proxftl.UUCP> Reply-To: bill@proxftl.UUCP (T. William Wells) Distribution: na Organization: Proximity Technology, Ft. Lauderdale Lines: 120 Summary: Expires: Sender: Followup-To: Keywords: In article gateley@mips.UUCP (Bob Webber) writes: > In article <430@proxftl.UUCP>, bill@proxftl.UUCP (T. William Wells) writes: > < Real enough? > > Commercial programming in Basic, database languages, COBOL, and RPG you > call REAL? I hate to disillusion you, but those languages still account for most of the programming being done today. > Phooey. Glad to hear you finally got to C -- sorry to > hear you got to it after all the fun. Well, I'll say that I am glad to have got to C. Believe me, programming in those other languages was a real chore. > < < < it not often being very useful to do this for C programs. > < < > < < Well, there is a free, high quality C compiler for 68000-based systems > < < and various others that does do tail recurision (i.e., gcc) among other > < < things. [However, it wouldn't catch this particular case -- perhaps > < < that is why you aren't using it? ] > < > < That's fine for 68000's (like the Sun I am working on) but not > < for IBM-PC's (our secondary machines) nor for the 100+ compilers > < our code is regularly compiled with. Relying on compilers to do > < tail recursion optimization would be slitting our own throats. > > Fine. From all the comp.binaries.* talk, I understand that it is a major > heroic effort just to compile a program on an IBM-PC, so we certainly > wouldn't expect you to have access to modern compiler technology there. > However, I see no point in crippling an entire generation of programmers > due to the limitations of the IBM-PC. You missed the point: I write programs so that they will be portable; unless you are doing research or are programming for a particular environment, so will you. That being the case, you'd better not write programs that work well for one compiler and fail for others. Also, keep in mind that the discussion on comp.binaries.* comes from the fact that most of the code that they are having trouble with was written by people who have or had little idea of how to write portable code. (This comes from an examination of some of the posted source code, it is not intended as a blanket condemnation.) 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. > < Sorry, but using purely tail recursive routines does not save > < time for this programmer. Anywhere you would use tail recursion, > < I'd automatically code a while loop. > > Yeah, well there are some people who never did catch on to recursion > -- but don't worry, I am not banning the while loop, just saying that > there is no reason for people to have to do that sort of coding when > they are trying to organize a large program. 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. > < So here is a third lesson for you: try to make everything you do > < as good as you can. The notion that a routine is only going to be > < used a small fraction of the time is no excuse for sloppiness. > < Even if the routines are only going to be used 1% of the time, > < those damn little routines can end up eating much of your > < program's run time. > <.... > < And a final point. You have encouraged sloppiness in writing > < strlen() by justifying it with "that routine is never going to be > < executed much anyway." Even granted that proposition you have > < forgotten an important point. If you do not make it a habit to > < write good code ALL THE TIME, that means two things: 1) Your code > < will be generally less efficient than it could have been. 2) > < When it comes time to write efficient code, you will not have > < the experience needed to do it. > > Sigh. Why spend your life writing the world's best strlen routine 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 certainly includes making decisions on how much effort you should expend in writing strlen. Which, in a given context, might mean writing it the easiest way possible, or it might mean optimizing it to death. 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 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. 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. > 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. > not need your super-spiffy strlen routine. It needs a stable operating > system, a compiler that works ALL the time, a screen editor that works > ALL the time, ... 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. Those who routinely make their best effort, investigate their options and their consequences, and remember that today's programs must be written for today's systems, write better programs than those who do not. 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.