[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. Saying that a language "satisfies nice properties" sounds abstract and useless to some people who just want to get things done, but I really believe that it helps not only researchers who know know how to read and use formal semantics, but also everyday programmers, because they absorb some of these reasoning methods and then start using them intuitively and unconsciously. For example, every Haskell programmer has some grasp of referential transparency, and uses it implicitly every time he thinks about how to structure or rearrange his programs. Of course, this argument holds for any "simple" language, not just functional ones, where by "simple" I mean "easy to reason about". For example, there are concurrent calculi of processes, object calculi and first-order algebraic languages which also share this property, and I prefer any of them to warty conventional languages. (And this is why I also like SML: even though it's not referentially transparent like Haskell, I know what sorts of properties it satisfies.)
Point Four: functional languages are difficult are learn. [..]
I would say "there is more in functional languages to learn about than there is in conventional languages". I get the feeling that programmers who come into FP from more conventional languages expect that FP will be just like C, only with a few new features and the syntax mixed up a bit, because if you look at the world of conventional languages---C, C++, Pascal, Java, Python, Perl, Ruby, FORTRAN---it is almost invariably true: there is hardly any difference between these languages, except surface syntax, and the fact that in some of them you have to macro-define what is a built-in in another. So they are all about the same level of difficulty, because they are really no genuinely new concepts, or at least they are not encapsulated in the language. Also, they are mostly implementation-defined: if you roughly know the von Neumann architecture, then you know what to expect. Haskell (and ML) really is different. First, it's not implementation-defined. Second, they satisfy some genuinely new properties. Some of these languages have closures, for example, but they don't obey the same properties as Haskell's higher-order functions because you don't have referential transparency. So you have to start thinking, "OK, is this one of those situations where I _can't_ use this property?", and pretty soon that's all you're thinking about---the exceptions to the rule. (At least, this is what happens to me in, for example, Emacs LISP, where closures can only be passed downwards.) In Haskell, you never have to think about that, because though the context may affect the efficiency of a program, it cannot affect its meaning.
Point Five: there's a dearth of libraries. [..]
Philip Wadler, "What The Hell Are Monads?"
The second one is by Noel Winstanley, not Wadler. --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791