holy hell why are tutorials like this always in haskell. While I am sure there are a lot of people using Haskell, there is a whole lot more people in Java or python.
1: Hey Underscore, You're Doing it Wrong!
(Rambda looks neat, thanks for the link.)
Spend some time learning the basic Haskell syntax (it's really not that hard) and you'll be able to get to the "meat" of such articles much, much faster than if the article were written in any other language.
In particular, are you really trying to write Haskell code in Java/Python, or are you writing Java/Python code and still wish you had monads?
If I have to use a monad for each operation, that feels like the same order of magnitude of effort as checking for null after each operation. If it's just one monad, then it feels like the monad saves work.
For that matter, the monad may still save work, because I only have to think about how I handle Nothing in one place, at the end of the series of calls. Whereas with null, I have to think about how to handle it after each call that can return null.
foo >>= bar >>= baz
foo >>= return . bar >>= baz
f x = fromMaybe defualtValue $ Just x >>= foo >>= bar >>= bazYou won't understand the fuss about keyless entry if your car doesn't have locks.
No, of course not. Are people without feet useless?
What does it mean to say that Java does not have feet?
It means that it lacks a capability for which it also lacks a need (shoes). This capability is that of expressing purity via the type system. Monads - and by extension, monad transformers - are a tool designed to assist the expression of imperative algorithms in a pure context.
The reason I phrase it this way is because people often make the mistake of assuming Haskell is lacking expressive power due to its purity. This is untrue. Haskell is perfectly capable of expressing messy, mutable, imperative algorithms just like any other language. Other languages, on the other hand, struggle to express many of the pure algorithms and data structures used in Haskell; they simply lack the ability to enforce purity within the language and are thus reduced to purity by convention.
I don't see the point you are trying to make here.
But that doesn't mean they are as useful in every language. So other languages don't NEED tutorials on monads as much as Haskell does. This isn't because those other languages are worse (less "principled" or "explicit") than Haskell. It's because they aren't structured to make it important to have tutorials on monads. Instead you worry about whatever the specific issues are for those other languages.
If you aren't quite comfortable enough with monads to follow the first link, I found this implementing monads in python tutorial[1] to be a huge help.
For those that want to play with Monads in Python, check out PyMonad[2].
0: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
1: http://www.valuedlessons.com/2008/01/monads-in-python-with-n...
The fact that everybody tries to import monadic values into their languages is evidence that they would indeed be useful; the fact that such libraries are always useless in practice and incapable of even transliterating the Haskell, and often fail to even implement the full feature set of monadic values in Haskell even if you're willing to type reams of code, is why you don't use them in other languages.
You don't ignore monads in non-Haskell languages because the other languages are too powerful to need them, hurr hurr Haskell is teh weaks... you ignore monads in other languages because those languages are too weak to usefully implement them. If they could, you'd see them, and I am very, very confident over the next 10 years you're going to see more and more languages coming out that really have and really use monadic values, because they will be strong enough to do so, and once you have that, the value proposition is just too good to ignore. They are too darned useful to ignore.
Could you give a bit more detail here? From where I sit, I certainly don't see people trying to import monadic values into the languages I use, and I don't see much evidence that they'd be useful. (I've been trying to get my mind around monads and when and how to use them, and one of the problems I have in learning them is that, as far as I can tell, they don't look like the solution to any problem I've ever actually had.)
By importing them, I mean by writing articles like this, which invariably produces code with such an overhead to use it that nobody ever would.
They don't appear to solve any problems partially because you're already "in" a monad; program execution flow is already a monadic value itself. They partially don't appear to solve any problems because you can't really "think" in them, because, as I mentioned, most languages are simply too weak to make them convenient enough to use. And they partially don't appear to solve any problem because the samples used by all the "tutorials" are all pretty trivial; it's sort of like dismissing Object Orientation because obviously it's only useful for modeling relationships between shapes, animals, and cars or something, since that's all anybody ever talks about.
And getting to write large amounts of my system inside monads (because of lots of mutable state)... that doesn't look like a solution to me. It looks more like a problem.
Are there high-level abstractions that would simplify my view of this? Probably. Would getting those abstractions to behave as needed on the low level be a net win, or a net loss? My money is on the "net loss" side.
See: http://dl.acm.org/citation.cfm?id=359579
Also, you might be interested in this: https://hackage.haskell.org/package/atom
If you care at all about security, then formal verification afforded by FP techniques should also interest you.
""" Atom
Atom is a Haskell DSL for designing hard real-time embedded software. At Eaton, we use it for automotive control systems. Based on guarded atomic actions, and similar to software transactional memory, Atom enables highly concurrent programming without the need for mutex locking. In addition, Atom performs compile-time task scheduling and generates code with deterministic execution time and constant memory use, simplifying the process of timing verification and memory consumption in hard realtime applications. Without mutex locking and run-time task scheduling, Atom can eliminate the need and overhead of RTOSs for many embedded applications. """
It's all in C#.
EDIT: you don't strictly need something like monad transformers, though. In general, monads are just another type class. A special one since IO is implemented with them, but other than that, they are not essential.