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