[Frank Atanassow
[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