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

[C. McCann]

On Tue, Oct 12, 2010 at 3:00 PM, Paolo G. Giarrusso
<p.giarrusso at gmail.com> wrote:
> 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.

Oh, for crying out loud, no it isn't. I don't have a PhD. I don't have
any graduate degree at all. I didn't learn anything about functional
programming back when I was an undergraduate at a
not-exactly-prestigious school, never mind category theory or abstract
algebra or any of that stuff, and I only started even learning Haskell
barely a year ago.

Arrows are easy to understand. Yes, really.

I'll agree that a lot of libraries on hackage could stand to have
better documentation and examples of usage--and I've not actually used
HXT itself so I can't speak to how well it does--but I honestly cannot
begin to imagine how using a fairly straightforward type class that's
part of the core libraries included with the most popular compiler is
a problem.

> When you write a library for general consumption (like here), you
> should strive to have a simple and effective interface for people.

Arrows *are* a simple and effective interface. Whether they're the
best interface to choose for any specific library is a trickier
question, of course, but that's because choosing how to structure a
library interface is always difficult.

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

There's only one way to express a general arrow with two inputs: Use a
tuple, because general arrows can't be curried. The discussion is
about converting a two-argument function to an arrow directly vs.
using one argument as a parameter to a function that constructs a
single-input arrow, and the only reason it's an issue is because the
syntax for supplying a constant argument to an arrow is a bit clunkier
than doing so for a function.

A better analogy might be programmers using some OO language
discussing whether some piece of usually-static data that an object
needs should be a method parameter (likely creating a bunch of
redundant code) or set just once by a constructor parameter (awkward
in those cases where it does need to change).

It is, as Sebastiaan Visser said, an engineering problem, not a
conceptual problem. Avoiding arrows would simply produce a different
set of engineering problems to consider.

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

I do get a little tired of finding libraries whose only documentation
consists of a couple papers, found in PDF form on the author's
university homepage (or worse, no documentation at all). But expecting
a library like HXT to walk someone through how to use libraries that
are included with GHC seems a bit unreasonable.

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

I don't like the idea that things need to be "dumbed-down" for general
use. Programmers aren't stupid and they can learn new ideas. Talking
about stuff like it's some crazy incomprehensible deep magic that only
super-geniuses can understand is silly and not helpful.

...Well, that all probably came out sounding harsher than I intended,
my apologies if so. I'm just a little weary of seeing ideas like
arrows made out to be more complicated than they really are; I
honestly think at least 90% of what makes them seem difficult is
people telling each other how difficult they are!

- C.