On 25-Jul-2001, matt hellige
agreed, and this brings up another issue that has, up to this point, not been mentioned... the well-understood (and theoretically guaranteed) properties of functional languages allow compilers/interpreters to do some much smarter things with functional constructs... this allows very abstract language features to be implemented much more efficiently.
That's nice, but it's not essential. I think the effect here is sometimes exaggerated. Could you be more specific about exactly which kinds of optimizations you are referring to here? If/when multiple-CPU machines become common, so that automatic parallelization is a serious issue, then it will be much more important. But currently the optimizations you're talking about don't make a huge difference, IMHO. Let's see, there's (a) better opportunities for optimizing away code whose results are not used (lazy evaluation, and related optimizations); (b) better opportunities for reordering code; (c) advantages from knowing that data is immutable; and (d) better opportunities for avoiding heap allocation because there are no problems with object identity or mutability. (E.g. this allows optimization such as static allocation of constant terms, common sub-expression elimination, and deforestation.) I think (b) and (c) rarely make substantial differences. (a) and (d) can be very important, but in those cases if you're programming in an imperative language you can always do the optimization manually.
to return to the original question: "why not just write in a functional style in an imperative language?" the answer goes beyond the (not inconsiderable) convenience of having a syntax designed around the style.
I think this is a lot more important than the optimization issues that you mentioned above. And while syntax is important, it's not just a matter of the syntax; semantic issues such as avoiding undefined/unspecified/ implementation-defined behaviour are important too, and there's also the standard library to consider. If you're going to be programming in a functional style it helps a lot to have a standard library that can support that style well.
aside: does anyone know whether the same arguments apply to object-oriented programming?
IMHO, yes, they do.
i know that people have, in the past, taken object design principles and applied them in a purely procedural language, claiming that the conveniences offered by a truly oo language were unnecessary.
It's true that these conveniences aren't necessary. But if you're planning to write a lot of code in an OOP style, they are certainly useful. I think this argument has mainly been heard in cases where there were other advantages to sticking with the procedural language.
does a truly oo language not offer substantial opportunities for optimization,
No, there are definitely some important optimizations that can be applied to OOP languages which are hard to apply to OOP programs written in procedural languages. In particular inlining of virtual method calls is one such important optimization, but this is more difficult to do in most procedural languages because there is no guarantee that the vtable remains constant.
can anyone recommend any good books/papers on this?
I suggest looking at papers on optimization of OOP programs,
e.g. the papers on the Cecil/Vortex project
http://www.cs.washington.edu/research/projects/cecil/.
Probably a browse through the proceedings of OOPSLA would
find lots of other relevant references.
--
Fergus Henderson