[Haskell-cafe] Re: A rant against the blurb on the Haskell front page

[Ben Franksen]

Don Stewart wrote:
>     ben.franksen:
>     > "Haskell is an advanced purely functional programming language."
>     > 
>     > Good start, if only the "advanced" were replaced with something more
>     > characteristic, like "lazy", or "statically typed". Which, BTW, both
>     > do not
> 
> "lazy" and "statically typed" don't mean much to other people. They are
> buzz words that mean nothing to many people.

I imagine a list of 'bullet points' following the blurb, listing the main
features with a small explanation and a link to further details.

>     > appear in the whole blurb, even though they are *the*
>     > characteristics of Haskell, lazyness being even something that sets
>     > it apart from most other languages. I hear the marketeers crying
>     > "but the average visitor has no idea what lazyness means". So what?
>     > Give them a link to the wiki with an explanation. So, a better
>     > introductory sentence would be
>     > 
>     > -> "Haskell is a lazily evaluated, purely functional programming
>     > language with a very flexible and powerful static type system."
> 
> What are the benefits of laziness?

It is difficult to explain lazy evaluation and why it helps to make programs
more concise in one sentence. But it still is *the* most distinguishing
feature.

And let us be honest: it has benefits and it also has disadvantages. The
most prominent disadvantage being that it makes reasoning about runtime
behaviour, i.e. performance, much more difficult.

>     > Next sentence:
>     > 
>     > "An open source product of more than twenty years of cutting edge
>     > research, it allows rapid development of robust, concise, correct
>     > software."
> 
> It is open source, and was born open source. It is the product of
> research.

How can a language be open source, or rather, how can it *not* be open
source? The point of a (programming) language is that it has a published
('open') definition. Nothing prevents anyone from creating a proprietary
compiler or interpreter for Haskell, AFAIK.

I do not dispute that Haskell is a reasult of research and I agree that this
should be stated. It is still not a 'product'. Have you ever heard someone
characterising TCP/IP as a 'product'? Or HTML? Or even C? The
term 'product', as it is used in the blurb, implies or at least suggests
some specific implementation, not a written and published standard.

>     > This really gets me every time I read it. How can anyone write such
>     > a nonsense? Haskell is not an "open source product"! It is no
>     > product at all. That most (maybe all) implementations are opens
>     > source is certainly an interesting fact, but IMO not something that
>     > should appear at the top of the page right under the header "The
>     > Haskell Programming Language". The second and third sentences
>     > deliberately conflate language and implementation(s). This is a well
>     > known falacy and I am ashamed that it
> 
> As Python, Ruby, C and every other language do.

Exactly my point. They all have only one relevant implementation. And in
practice this implementation has a great tendency to be taken as the
*definition* of the language, at least w.r.t. its semantics.

Do I really have to explain why this is bad and why specification of a
language should be clearly separate from its implementation? (Hint: how can
you ever hope to prove something about a piece of code if all the semantics
you have is "whatever the implementation does"?)

I *love* it that there *do* exist other implementations for Haskell, and I
dearly hope UHC, JHC etc will soon get to the point where they can be used
and recommended for practical programming.

>     > That cutting edge research is done for Haskell as well as for its
>     > implementations is of course good to know, but just stating it is
>     > not nearly enough: such a statement must be corroberated with
>     > evidence, otherwise it is just idle marketing. (Not that there
>     > wouldn't be evidence amass, it's just that none is given.)
> 
> You literally want evidence that research played a part in Haskell, in
> its opening statement? Why??

I reject this objection. I let myself get carried away here. Still I think
that further down some links can be given to papers about Haskell and its
implementation.

>     > On we go:
>     > 
>     > "With strong support for integration with other languages, built-in
>     > concurrency and parallelism, debuggers, profilers, rich libraries
>     > and an active community, Haskell makes it easier to produce
>     > flexible, maintainable high-quality software."
>     > 
>     > Let us take that apart:
>     > 
>     > (1) Fact: Haskell has a good and very easy to use FFI. To the C
>     > language. I have never heard of integration with any other langauge
>     > being directly supported.
> 
> It is OK to contest these, but consider the FFI of our competition:
> Python, Ruby, Erlang. Woeful FFIs. You are not at risk using Haskell, as
> you can always call out to your favorite $language library.

You misunderstand: I *love* Haskells FFI. It is the best I have ever seen in
any langauage. It is far superior to the competition.

And I agree that this is a strong selling point for Haskell. BUT: it is
still (currently) to C only. We cannot offer something like the tight
integration of e.g. C# and F# in .NET or similar language independent
runtimes.

>     > (2) Fact: Built-in concurrency and parallelism is not exactly part
>     > of the langauage, although purity makes it possible to support them
>     > in a more precise and less error-prone way; which is exploited by
>     > ghc's concurrency and parallelism extensions.
> 
> Haskell since 1990 has been a bed for trying out new parallelism and
> concurrency ideas. Current implementations, particularly GHC and GPH/GDH
> support forms of parallelism the combination of which is available
> nowhere else.

I agree completely. Why not say so?

>     > (3) Fact: Traditional debuggers are practically useless in Haskell,
>     > due to lazy evaluation. But, oh, we forgot to mention the small fact
>     > that Haskell is lazy. Too bad. Profiling is supported by ghc only
>     > (AFAIK), but is supposed to be very useful (never seriously used it,
>     > so I can't judge.)
> 
> GHC has a built-in debugger. You should not be scared of Haskell's
> support for finding bugs.

First, Haskell's strong point is *avoiding* bugs. A very large portion of
the research on Haskell is about leveraging the type system to get more
static guarantees. One of the main selling points of Haskell, to me at
least but I have heard others saying similar things, is that you spend a
lot less time in debugging. It is the famous "once it compiles it typically
just works" (which is of course quite a crude approximation of reality).

Second, how many people are actually using the ghci debugger to find bugs in
their code? Is it just me being slow to adopt this feature?

>     > (4) Fact: there are libraries. Some of them are good, others are not
>     > so good. Most leave a lot to be desired, but I would be hard pressed
>     > to come up with something better myself. What really distinguishes
>     > Haskell libraries from what is found in other languages is the level
>     > of abstraction. I know no other language where stuff like Monad,
>     > (Applicative) Functor, Monoid, Category etc. is *at the heart* of
>     > all the libraries. But, oh, I forgot, we don't want to scare people
>     > off, so better not talk about this in public.
>     > 
>     > (5) Fact: Haskell has an active community. No question.
>     > 
>     > (6) Fact: Haskell makes certain things easier (than other
>     > languages). Other things that are easy in other langauges are hard
>     > in Haskell. Or at least very non-obvious. Whether Haskell programs
>     > are more flexible, when compared with dynamically typed OO languages
>     > like Python, I seriously doubt. Maintainable high-quality software
>     > is the real selling point, IMO; or rather *reliably correct*
>     > software. However, I cannot see how this dirtectly follows from the
>     > previous points, which is what the sentence is saying. What has an
>     > FFI do to with high quality? What has the supposed availability of
>     > debuggers (where? which?) to do with it?
> 
> These are precisely the reason that e.g. Galois uses Haskell.
> Maintainable, concise, correct software.

I am not disputing this.

>     > Enough. I think I have made my point.
> 
> What's your point?

My point is that Haskell should be represented honestly and in a language
that reflects its main characteristics: Elegance, precision, abstraction.

Learning Haskell is hard. The benefits, once you get over the initial
hurdle, are enormous, but to get there can mean lots of frustration.

Learing to master it is a life long task (or it seems to me, at least). And
that is a *good* thing: there is always more to disvover. It is one of the
reasons I am still mostly interested in Haskell and haven't moved on to
something else.

> What alternative do you suggest?

I am not yet ready to present an alternative proposal but I am working on
it.

Cheers
Ben