On Tue, Oct 12, 2010 at 3:00 PM, Paolo G. Giarrusso <p.giarru...@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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
