From: bqt@Minsk.docs.uu.se (Johnny Billquist)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 19 Aug 92 11:42:57 GMT
Organization: UDAC, Uppsala, Sweden

In <repo.037m@depo.UUCP> repo@depo.UUCP (repo man) writes:

>In article <1992Aug14.081326.24359@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>
>>This gets to the heart of the matter: hll programmers depend on the compiler
>>to do "magic" of various hues and colors for them; for most of them, they
>>haven't a clue as to what's going on, and the best they can do is to "tinker"
>>with what little options are available to them, namely the command-line
>>switches to operating the compiler.  They have given over so much control
>>of the ultimate running code to the compiler that they can never take it back.

>All I expect from a compiler is to produce the most efficient code it can,
>with the least amount of hassle.  Lets face it, most compilers do a more than
>reasonable job of producing efficient code for most applications.  Ever use
>GCC?

How can you tell, when you don't even know what code it generates?
I suppose you've been listening to "people_who_know" who says so.

>Not everyone shares your obsession with assembly language, nor does everyone want to take compiler-optimization 101.  You are also insinuating that high
>level language programmers are generally less adept than assembly language
>programmers, which is utter nonsense.  I personally am more interested in
>portability, than limiting myself to using 68000 exclusively.  'C is usually
>quite sufficient for my needs, but like life there are always exceptions.

I can accept that some people doesn't like assembly language, that's ok.
I can also accept that hll programmers are just as adept as assembly
programmers. I cannot accept that a compiler would be smarter than a
programmer. If you put more abstractions between you and the machine,
you will have to accept that you get less control over what really happens.

>I think the tools used to develop your application should be determined
>directly by the scope in which the application will be used.  That is,
>programs such as file compression utilities and the like should be developed
>with portability kept strictly in mind, whereas some program which exploits
>unique features of hardware should obviously be done in a lower-level
>language.  The bottom line is, anyone who limits their experience for
>whatever reason is only fooling themselves.

Amen. But you should not assume that someone (Lasner) has limited
his experience. He might very well have tried the hll:s, and come
to the conclusion that they don't give him what he need.

>>Admittedly there will be unusually qualified hll writers who truly understand
>>how to make the compiler do what they want.  So, instead of tinkering with
>>the option switches, they tinker with the code.

>My compiler does EXACTLY what I want.  Of course, my program may be slightly
>slower than yours, which does the same thing, but if its not some time
>critical routine, then what's the point?  What's more, while you're still 
>optimizing, I'm finished and have written another program.  This whole
>argument is beginning to resemble the CLI/GUI argument.

Oh yeah? How does the compiler know exactly what you want? Does it ask
you 101 questions, or does it read your mind?
Face it once and for all. Compilers don't know what you want, so they
do exactly what you say, and hopes you know what you want.
It's often not easy to do things optimally in this way, but it has
a fair chance of working.

>>By and large, assembly language programmers *do not* tinker.  I don't want to
>>know if a compiler may/may not do it the "right" way.  I know that as an
>>assembly programmer I can ensure that myself.  Even those better-qualified
>>hll code-writers have to admit that they sometimes use assembly language
>>in spurts to correct limitations of the compiler, thus they are still
>>tinkerers, because effort is going into deciding where to apply how much.  This
>>seems to imply a moving target with the attendant problems.

>Must everyone know exactly how a microwave works, to determine the precise
>time and setting required to produce the perfect cheeseburger?  The answer is
>no.  Most people couldn't care less HOW it works, only that their burger
>comes out neither over nor undercooked.  The whole idea is to be productive,
>and that is entirely subjective.

Nope, you don't need to know how a microwave oven works to heat
a chees burger. To call this cheesburger perfect is a lie every
day though. To get a perfect cheesburger, get yourself a cow,
a knife, a fryingpan or an open fire. Cut and chop the meat from
the really good parts of the cow, and cook it.
Don't heat it in a microwave, that produces something edible, not
something perfect.
Then there is the question of cheese as well...
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
Newsgroups: alt.folklore.computers