Re: Languages of multiple abstaction

Gary Duzan <gduzan@acm.org>
5 Nov 2006 23:35:35 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: Languages of multiple abstaction DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-11-01)
Re: Languages of multiple abstaction torbenm@app-0.diku.dk (2006-11-01)
Re: Languages of multiple abstaction bmoses-nospam@cits1.stanford.edu (Brooks Moses) (2006-11-01)
Re: Languages of multiple abstaction walter@bytecraft.com (Walter Banks) (2006-11-01)
Re: Languages of multiple abstaction free4trample@yahoo.com (fermineutron) (2006-11-04)
Re: Languages of multiple abstaction gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-11-05)
Re: Languages of multiple abstaction gduzan@acm.org (Gary Duzan) (2006-11-05)
Re: Languages of multiple abstaction marcov@stack.nl (Marco van de Voort) (2006-11-08)
Re: Languages of multiple abstaction gene.ressler@gmail.com (Gene) (2006-11-08)
| List of all articles for this month |

From: Gary Duzan <gduzan@acm.org>
Newsgroups: comp.compilers
Date: 5 Nov 2006 23:35:35 -0500
Organization: Compilers Central
References: 06-10-12606-11-006 06-11-014
Keywords: design
Posted-Date: 05 Nov 2006 23:35:35 EST

fermineutron <free4trample@yahoo.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
their heads.


                                                                                Gary Duzan


Post a followup to this message

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