Re: Languages of multiple abstaction

fermineutron wrote:
> It is interisting to see that I got rather differet answers than what i
> expected, which is good, because it enriches the mind.
>
> Anyways, here is a followup question:
> Why do "real" programmers still bother with low level languages when
> they need speed, if HLL will allow in some cases faster code, since the
> data structures are static.
>
> It seems to me that if we are to consider 3 levels of abstraction:
> 1) Assembly language
> 2) Low level of abstraction, C.
> 3) High level of abstraction, something like MatLab
>
> Now if due to its static nature languages of level 3 can match
> languages of level 2 in runtime, then how come C is still the language
> of choice for 99% of serious programmers? Obiously portability, but
> for specialized tasks such as scientific computing, it is unlikely
> that the program will ever be used after its done its job, like
> protein folding and other highly specialized apps.
>
> Also, most pepole would admit that Java is slower than C, so since its
> slower than C, yet there is no fundamental restriction of speed based
> on the level of abstaraction, how come it has not beeen re-optimized
> to match C? Sun definitely got the resources for it.


Four comments:


0) Tools of apprenticeship: C has immense appeal because it's small
and easy to learn. I personally believe its very structure has a
certain quirky appeal to the kind of mind that likes coding. It's
dangerous and that's cool, a testosterone thing. And it sticks. My
old boss used to say "Men are slaves to the tools of their
apprenticeship." This is amazingly true. (Too bad he could not
remember the attribution.) Given this, see 3).


1) Rule of the market: Sun stops working on Java speed optimizations
at the exact point where marginal profit drops below marginal expense.
Probably there are speed opportunities remaining. (There is a massive
literature on Java and JVM optimization. Don't know how much of this
has ever been put into Sun's implementation.) But there are very,
very few applications where the speed difference makes a bottom line
difference. "No incentive, no improvement." Triggering 7-year old
bugs in MS Word at least once a week reminds me constantly of this
one.


2) Caveat benchmark: C's reputation for speed is rooted in small
benchmarks that don't represent real applications very well. After
you hand-code the memory allocation, the index checks to prevent
buffer overflows, the traps for every possible error condition, vtabs
for dispatching on type, etc. etc. needed in well-implemented systems,
the speed difference pretty much vanishes. The exception is low-level
algorithms and inner loops where some of the above can be
hand-optimized away with careful algebra. You can do this in C, but
in Java and other HLLs, if the compiler doesn't do it for you, you
have little ability to "roll your own." That's why many of the HLLs
have foreign C interfaces (and C has an assembler interface!).


3) Lifecycle costs: A more general observation is that language choice
almost never depends on nicities like speed or elegance (closeness of
mapping from concepts to constructs). Rather it's preference of the
programming staff (see 0), existing expertise (read training costs),
legacy code compatibility (read sunk costs), license and library
issues (more sunk costs), and -- sometimes -- fad-of-the-moment
prejudices of uneducated management types. Again economics are in
charge. More/faster hardware (to compensate for slow
languages/impelementations) and a few more coders (to e.g. translate
concepts into arcane C constructs) are usually tiny costs in a big
project. There are many, many studies showing that functional and
even higher 2GLs like Ada have great advantages over C and its ilk and
tiny relative disadvantages. Too bad these tend to be swamped by all
the above.

Return to the comp.compilers page.
Search the comp.compilers archives again.