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