🚀 go-pugleaf

In article <2850@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes:
>
>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.

I guess you never actually had to *sell* a program :-).  While I would like
never having to worry about how a language is implemented, I can't get my
job done well if I don't.  It would be nice if we could program assuming an
infinite amount of memory and infinitely fast processors, but neither of
those things exist (yet :-)).

For example:  two days ago I implemented a nice concise algorithm for
parsing.  When I tried to run it, I got a memory error.  It turns out that
it was due to the garbage collection scheme the language I was using
implemented (something which I have no control over).  I ended up having to
reimplement the algorithm so that it accounted for garbage collection.

Another example:  when I was first learning Pascal, I was using an Apple II
+ with 64K of memory.  I learned very quickly how large the stack space was
because many of my consise (and usually recursive) routines would bomb with
a fatal error.


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.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah