I have no idea what a Kleisli arrow is, and a simple Google search points me right back in the direction of the HaskellWiki. They may be a perfectly simple concept, but if they are, then the term is not in widespread use. One of the major problems with explaining monads is that programmers who understand them frequently attempt to explain them by using terms even less well-understood than "monad". You get points for precision, but none for evangelism.
It is of no help or use to those who do not understand monads that they could also be an applicative functor, or comonad, or whatever. You may be perfectly correct, but for someone who is not already part of your community, and conversant in its terms, it does not particularly help.
A Kleisli arrow is just an arrow that works like a monad:
-- | Kleisli arrows of a monad.
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }
instance Monad m => Category (Kleisli m) where
id = Kleisli return
(Kleisli f) . (Kleisli g) = Kleisli (\b -> g b >>= f)
I only brought it up to show that we can use the same operator, Control.Category.., to compose functions, monads, and arrows and that they are not all that different from each other.
(It's also worth noting that every language has their own language-specific terminology. If I Google for "std::string", I am only going to find C++ results, despite the fact that strings are a generic concept. If I search for "IEnumerable", I am only going to get C# results, despite the fact that enumerations are a generic concept.
Similarly, not many languages think of programming in terms of arrows and objects and categories, so you don't see many results for "Kleisli arrow" outside of the Haskell community.
Way to make his point. Only programming language where Arrows ever come up, Haskell. Wiki page on Arrows "Generalized Monads". So far our definition of a Monad is a specialized version of the generalization of Monads.
Hear hear. I looked at Haskell years ago, liked the functional aspects, recursion, lists, etc., but monads for I/O, database, was like hitting a wall. Switched to ocaml, it had enough imperativeness for that, but I got turned off when I got to functors of modules or something like that. Worked in Common Lisp for a while, but now I'm happy in Clojure, I got back the FP but I don't need a PhD for talking to a database.
Problem is, when you use a programming language without arrows, you end up rewriting generic plumbing every time. If you want to write more code in your app to avoid using the word "monad", that's fine, but probably not rational.
This has nothing to do with the use of monads, but how they are explained. When your explain monads to people who don't no what monads are speach starts with "It is an arrow..." You are explaining monads to yourself, not to someone who doesn't understand monads (and consequently doesn't have a clue what arrows are.)
So far as I can tell monads are abstraction of state(though calling them abstractions of function application is more correct, calling it state is more intuitive to me, and how they are represented in the type system.) From there they get used for different things: Maybe == Nullable Types, List == lists, Either == Unions, St == Mutable State, IO == hide IO. Then a function that is pure and doesn't know about what your monad does gets invoked by the monad where the hidden state changes the flow of computation. Maybe performs a null check, List calls map, Either picks the type in the union then calls the function on that, St allows you to use and update the hidden state, IO performs IO then shares the result with you.
Now there is an explanation of a monad that doesn't assume you already know what a monad is. It may not be good since it basically says monads are sticky higher order functions masquerading as a data type, but there you have it.
Honestly, I'm tired of explaining monads in every HN article about Haskell. I've written detailed explanations for newbies 100s of times. If you want to learn more about something, Google it.
Remember, you understanding Haskell will improve your understanding of the Universe. You understanding Haskell will do nothing for me. So you can see how the incentives are aligned...
I don't disagree that every technical community has its own terms. But it's very difficult to broaden that community by restricting yourself narrowly to those terms. To me, "an arrow that works like a monad" reads like a recursive definition: if you don't understand how one works, you can't understand the other.
The net effect is that your community is going to be composed of people who made a conscious effort to break through the communication barrier. This isn't necessarily a bad thing; you end up with a small, focused group of very smart people. But it doesn't buy you many converts in the industry.
When a function uses global state to compute a value, it's like the global state is an argument to the function.
When a function modifies global state, it's like it returns both the value it computes and the modified global state.
If you're interested more you can read http://research.microsoft.com/en-us/um/people/simonpj/papers... which I believe is the original paper introducing monads into Haskell. The first 11 pages are very approachable and give you the rational for why monads are necessary in Haskell and what they're for.
It is of no help or use to those who do not understand monads that they could also be an applicative functor, or comonad, or whatever. You may be perfectly correct, but for someone who is not already part of your community, and conversant in its terms, it does not particularly help.