newbie conceptual question [from haskell list]

[matt hellige]

[Frank Atanassow <franka@cs.uu.nl>]
> [redirected from haskell@haskell.org to haskell-cafe@haskell.org]
> 
> David Hughes wrote:
> > > It seems to me that I can still use functional
> > > programming paradigm with an imperative language. How can I benefit more
> > > from a functional programming language (i.e.Haskell)?
> 
> > Point One: functional languages are powerful. [..]
> > Point Two: functional languages are beautiful. [..]
> > Point Three: functional languages are robust; [..]
> 
> These things are nice, but the more I learn about functional languages, the
> more I feel that they are only icing on the cake. The most important thing
> about functional languages is that we know _what they are_, and that they
> can be characterized in a regular fashion which is amenable to analysis; in
> other words, we know how to reason about them, and what sorts of properties
> functional programs satisfy.
> 

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. 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.

no matter how referentially transparent all of your c code is, for example, the
c compiler cannot take advantage of that fact, because it cannot, in general,
rely on it. in a haskell compiler, however, that feature of the language is a
significant source of optimization opportunities. the same goes for the type
system. to implement higher-order functions and polymorphism in c or python,
the burden is, in general, on the programmer to verify that the program remains
well-typed. this commonly involves much wailing and gnashing of teeth, or, less
commonly but more safely, potentially expensive runtime checks. in a functional
language, the program is known to be typesafe at a relatively early phase of
compilation, and the type system is well enough understood that any
optimization the compiler performs will be type-preserving. so runtime checks
are avoided, as is the gnashing of teeth. :)

these facts, coupled with the fact that writing in a "functional style" in
an imperative language in the most obvious way can be very bad for performance
(e.g., too much recursion without tail-call optimization) motivates another
very good reason to use a functional language when you want to write functional
programs. to put it very simply, it's a case of choosing the best tool for
the job.

aside: does anyone know whether the same arguments apply to object-oriented
programming? 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. does a
truly oo language not offer substantial opportunities for optimization, or
is it a matter of oop still not resting on a sound enough theoretical
framework? can anyone recommend any good books/papers on this? is cardelli
and abadi's "theory of objects" a decent place to start?

m

-- 
matt hellige                  matt@immute.net
http://matt.immute.net