[Haskell-cafe] Re: Channel9 Interview: Software Composability and theFu ture of Languages

[Benjamin Franksen]

Steve Schafer wrote:
> Neil Bartlett wrote:
>>It also highlights some of the misconceptions that still exist and
>>need to be challenged, e.g. the idea that Haskell is too hard or is
>>impractical for real work.
> 
> Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't
> be here, obviously. Haskell is hard in the sense that in order to take
> advantage of its ability to better solve your problems, you have to
> THINK about your problems a lot more. Most people don't want to do that;
> they want the quick fix served up on a platter. And even the
> "intermediate" camp, the ones who are willing to invest some effort to
> learn a better way, are only willing to go so far.

I agree, but I think it should be pointed out that primarily it is not
Haskell which is hard, it is Programming which is. Haskell only reflects
this better than the mainstream imperative languages. The latter encourage
and support operational reasoning, i.e. creating and understanding programs
by mentally modeling their execution on a machine. This form of reasoning
appeals to 'common sense', it is familiar to almost all (even completely
un-educated) people and is therefore easier acessible to them.

Haskell (more specifically: its purely functional core) makes such
operational reasoning comparatively hard(*). Instead it supports and
greatly simplifies denotional resp. equational reasoning(**), i.e. to
understand a program as an abstract formula with certain logical
properties; an abstract entity in its own right, independent of the
possibility of execution on a machine. This way of thinking is less
familiar to most people and thus appears 'difficult' and
even 'impractical' -- it requires a mental shift to a more abstract
understanding.(***)

What the hard-core 'common sense' type can't see and won't accept is that
denotational reasoning is strictly superior to operational reasoning (at
least with regard to correctness), if only because the latter invariably
fails to scale with the exploding number of possible system states and
execution paths that have to be taken into account for any non-trivial
program.

As Dijkstra once said, the main intellectual challenge for computer science
resp. programming is: how not to make a mess of it.

Those who don't want to think will invariably shoot themselves in the foot,
sooner or later. Their programs become a complex, unintelligible mess; the
prefered choice of apparently 'easier' or 'more practical' programming
languages often (but not always) reflects an inability or unwillingness to
appreciate the intellectual effort required to avoid building such a mess.

Cheers
Ben
(*) The downside of which is that it is also quite hard to reason about a
program's efficiency in terms of memory and CPU usage.
(**) At least the 'fast and loose' version of it, i.e. disregarding bottom
and seq.
(***) Many Haskell newcomers have described the feeling of being 'mentally
rewired' while learning programming in Haskell. IMO this is a very good
sign!