sommar@enea.se (Erland Sommarskog) (03/21/88)
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