Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0

[Paolo G. Giarrusso]

Dear Sebastiaan,
I would first refer to the description of the "Change function" in a
paper by Erik Meijer (an Haskeller among the designers of F#):
http://portal.acm.org/citation.cfm?id=1297027.1297078
In short, programmers will learn something new only if the improvement
is worth the effort of the paradigm shift.

Below I add my opinions on the specific problem. A disclaimer: I am
unfamiliar with monads myself, I claim awareness of a meta-problem,
which is IMHO more important.
On Oct 12, 3:29 pm, Sebastiaan Visser <hask... at fvisser.nl> wrote:
> Gregory,

> I use arrows (especially list arrows) in a lot of my projects and find them (after some training) easier to work with than monands. Code that I write point-free using arrows generally contains fewer bugs than code I write in monadic style.

> I think it is unfair to say that arrows add complexity over monads. This statement can only be true to people who actually know monads and do not know arrows. This has more to do with the direction of one's knowledge than the 'complexity' (whatever this means) of a programming abstraction.

Were you writing a paper, your comment would be fully valid. Here
we're talking about a library for people to use in practice. In the
middle, somebody should make sure that people without a PhD can learn
arrows, by providing documentation. The problem might be just
educational, and it's not restricted to arrows, but it is still a
valid problem.
When you write a library for general consumption (like here), you
should strive to have a simple and effective interface for people.

Try to think of what's happening. Even the existence of this thread is
surprising. Haskell programmers, and experienced ones, are discussing
about how to express a two arguments function with arrows.
Can you imagine a C programmer asking that? The answer would be "RTFM"
or "STFW", or less polite than that. And that's GOOD. You can use
arrows because you got an useful intuition of them. Good for you.

The problem is partially the same as with monads, only to a greater
extent: monads can be easy if you don't try to relate them to category
theory, and they are indeed considered easy in F# (see the same
paper). Again, the problem is maybe mostly educational, but it is
entirely valid.

Of course, the root question is: what is the purpose of Haskell?
1) Is it to produce pure research, which might then be reused in
production to actually affect software engineering, and used directly
by blessed PhD students?
2) Or should Haskell be used as such?
Some people argue for 2), but the "research bias" of the community is
still quite strong. And you can't achieve 2) well working with a
research methodology. For instance, somebody needs to write _complete_
documentation (I see there is some, but it doesn't cover the basic
questions you are discussing), intended for users, rather than papers.
Like it happens for any other language.

Of course, nobody _has to do_ anything. I'm a PhD student, I couldn't
work on any of this because it wouldn't count for my career. But at
least I'm aware my work won't be usable for purpose 2). (Intermediate
situations, like writing a paper _and_ a dumbed-down version for
general consumption, are also possible of course).

Best regards