🚀 go-pugleaf

I wrote:
>What is quite evident from this debate is that the programmer 
>shouldn't really bother about this. His main task is to express 
>the solution of the problem as clearly as possible in the language 
>he is using. He should not bother too much about such things as globals
>vs. locals. What may be fast one compiler may be slow on another
>and vice versa, depending on the technique they use.

And Nevin J Liber (nevin1@ihlpf.UUCP) gives some examples and concludes:
>A programmer should always try to take into consideration how the language he is
>using is implemented.  His/her task is not only to express the solution to
>a problem clearly and easily, but to express it so that his/her solution
>will work given real-world constraints.

First: 
   A main problem when writing a program is to find out what it 
   should do. What the functional requirements are etc. I think
   everyone recognize the situation where the specifications are
   incomplete if existing at all. And even if there are good spec:s
   available, many questions are likely to turn up while coding.
   Particulary this is true, if the program contains a user interface
   of some sort. 
     My view is that it's too complex to keep track of what to do and 
   how to do it effectively, and that one therefore should concentrate 
   on the first thing. You have no use for an efficent program that
   does it all wrong. 
     Now, when your program works, look for bottlenecks and try to
   speed up slow parts. Here you may glance at the implementation of
   the language.

Second:
   Software are written during different circumstances. Some software
   may be a part of a specific system for a specific customer and
   is to run on a particular machine.
     Others are products to be sold to anyone, but directed to one
   type of machine, e.g. PC.
     Even more general are software programs that is supposed to run
   virtually any machine and any OS.
   
   The more general your sofware should be, the more dangerous is it to 
   take the implementation in regard. Of course, things that tend to be 
   common between different architectures can always be regarded. But one
   should not bother about e.g. displays. One implementation may have it,
   another not.
     But, even in the specific case, certain tweaks to speed up a 
   program may be bad. Say, that you have concise way to express
   a certain problem. It turns out that it compiles to quite bad
   code. So you add some help for the compiler, which obscures the
   code for the human reader. In next step, the compiler is re-written,
   and now compiles your concise code satisfyingly. You end up with
   code that is unnecessary complex and harder to maintain.
   
Finally:
   I agree with you so far that the programmer should have a general 
   feeling for how languages are implemented, I mean call stacks
   and such. But he should not have the burden to know what is
   specific for his compiler, until he runs into problem because of
   bugs or too little memory.
-- 
Erland Sommarskog       
ENEA Data, Stockholm        
sommar@enea.UUCP           "Si tu crois l'amour tabou...
                            Regarde bien, les yeux d'un fou!!!" -- Ange