Jeffery Holtmyer has commented to an earlier post regarding the efficiency of high-level versus low level coding.
Please fill this out with how the higher level languages create efficiencies or do not. Most of the people I talk with correlate a higher level language with higher efficiency in the code.
To my mind, the reason for the confusion here is that we are talking about two different efficiencies.
Well written assembler code will typically be more efficient running than that compiled from a higher language. The compiler has general purpose rules for conversion and since it has no real comprehension of what it being done, cannot make adjustments for context, etc. It may introduce unneeded complexity in order to be able to get many different things right.
If certain areas of code are critical, or run very frequently, then these may be targeted for rewriting in assembly code by a development team.
All this said, people have spent years optimizing compilers, and the emphasis is generally on improving areas of least efficiency. So it is possible that some compilers may actually produce better code than your average assembly programmer. (Although, since assembly is a rather arcane area, I imagine most programmers in that specialty are rather good.)
Another consideration is that by writing in a high level language you have access to sets of routines that that have been built by specialists in the particular field who have made a huge effort in optimizing it at critical points. Using these “calls” will get you very efficient code.
– other efficiency
So, while lower level languages may get you more efficient code, since you need many more lines to be written and tested, it takes much more time to write them. The difference is enormous.
This is compounded by the fact that programmers tend to write more or les the same number of lines of code per day, regardless the language.
David Thornley comments in a blog post:
Without actually checking my copy of “The Mythical Man-Month” (everybody reading this should really have a copy readily available), there was a chapter in which Brooks looked at productivity by lines written. The interesting point, to him, was not the actual number of lines written per day, but the fact that it seemed to be roughly the same in assembler and in PL/I (I think that was the higher-level language used).
Brooks wasn’t about to throw out some sort of arbitrary figure of productivity, but he was working from data on real projects, and for all I can remember they might have been 12 lines/day on the average.
Given that, I would disregard any actual productivity number he came up with as useless; the continuing value of the book is in the principles and more general lessons…
Note: The surprisingly low figure has to do with the fact that programming includes huge amounts of time planning, testing, waiting to compile, meetings, etc.
[BTW – the whole forum thread is quite provocative if you are interested in the topic.]
The point for this discussion is that high-level programming is always more efficient when you are talking about programmer efficiency, and this is the efficiency that is related to the cost of a project.
The smartphone and computer programs of today would be totally impossible if we all had to program in assembler.
A computer is an enormous onion with layers upon layers each built upon the next one down. Few people understand much about any layer more than one or two down from the one in which they work.
– last word on efficiency
So the confusion in the issue that Mr. Holtmyer raises results from a confusion in semantics – which efficiency are you referring to?
Comments greatly appreciated!
Dear friend – if you appreciate my commentary please consider viewing my product linked below.
Elegant, Handcrafted, Genuine Leather