newbie conceptual question [from haskell list]

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

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