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