Fast/slow languages (was Re: Unsafe Optimizations (formerly Compiler Design in C...))

>Of course, all of the slower languages have features that often make up
>for the speed trade offs, but if you don't need these features, there's no
>point in programming in a language that has them.


You never need those features. You can always do it in assembly language
(and other languages with user-hostile features). OK, let's correct the
statement to: if you don't want these features, there's no point in
programming in a language that has them. This idea still seems to be
popularly held, but I think it's a mistake.


There are a lot of programs which could benefit by being first designed
to work correctly, then modified to be fast and small. It seems reasonable
to want slow-but-powerful features at the beginning, fast-but-rigid
features at the end, and not necessarily have to translate from one
language to another during this process.


There are a lot of programs that benefit from maintenance, from making some
static characteristics dynamic in ways that the original designers did not
imagine. This is often done by translating from one language to another.
Perhaps the biggest exception is that C programs can often be mixed with
C++ programs without being translated -- but everyone expects existing
libraries etc. to be translated anyway. It would be nice to avoid this
translation step. It is nice to use a powerful language and try to avoid
expensive features when not necessary, but have still them available at
maintenance time.


(Disclaimer: every employer that I have ever worked for has disagreed
with such ideas.)
--

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