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

[Andrew Wagner]

I thought it was very telling that, at the end of the interview, when
the interview asked, "In general, where is programming going?", the
responses were all things that haskell is good at. Shame it's such an
"impractical" language.

On 1/26/07, Benjamin Franksen <benjamin.franksen at bessy.de> wrote:
> 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!
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>