newbie conceptual question [from haskell list]

[Fergus Henderson]

On 25-Jul-2001, matt hellige <matt@immute.net> wrote:
> 
> 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 <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.