|[5 earlier articles]|
|Re: Languages of multiple abstaction DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-11-01)|
|Re: Languages of multiple abstaction firstname.lastname@example.org (2006-11-01)|
|Re: Languages of multiple abstaction email@example.com (Brooks Moses) (2006-11-01)|
|Re: Languages of multiple abstaction firstname.lastname@example.org (Walter Banks) (2006-11-01)|
|Re: Languages of multiple abstaction email@example.com (fermineutron) (2006-11-04)|
|Re: Languages of multiple abstaction firstname.lastname@example.org (glen herrmannsfeldt) (2006-11-05)|
|Re: Languages of multiple abstaction email@example.com (Gary Duzan) (2006-11-05)|
|Re: Languages of multiple abstaction firstname.lastname@example.org (Marco van de Voort) (2006-11-08)|
|Re: Languages of multiple abstaction email@example.com (Gene) (2006-11-08)|
|From:||Gary Duzan <firstname.lastname@example.org>|
|Date:||5 Nov 2006 23:35:35 -0500|
fermineutron <email@example.com> wrote:
=>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.
I believe the main point about C is that it is "the devil you
know" versus the one you don't. If you're familiar with C and know
it can do the job, often it is easier to go ahead and use it.
Looking for alternatives which might be better but could end up
being broken or too slow can be risky and time consuming. Nevertheless,
I'm a big believer in using the right tool for the right job, so
I'll tend to look, anyway.
=>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.
I think it is a question of getting the right abstractions. If
your abstractions don't map well to your machine, it will be slow.
If your abstractions don't map well to your problem, you will have
to do the additional work to make it fit.
The ideal solution is a domain specific language tailored to
your problem. However, given the work involved in putting together
an optimized compiler, it only makes sense to do it for a well
defined, reusable set of abstractions. It's this area where I don't
see enough work being done. It is too easy to put together a C
library and make all the users of it deal with the idiosyncrasies
of the underlying language, when a new language would allow the
users to work with abstractions that are closer to the ones in
Return to the
Search the comp.compilers archives again.