re: Monads explained by their purpose VIEW POST


This is probably useful but all the monad explanations I've ever seen use Haskell or other non-mainstream language. And the idea that I have to learn that language prior to understanding some part of it is kinda backwards, no? I'd love to see monads explained in Java, C++ or at least Python. I know about Java's Optional being a monad but that's all. It's unlikely someone would change their primary language just because of some cool concept that exists in another, to put it bluntly, obscure language. On the other hand if that concept is applicable in a mainstream language everyone would be able to adapt it to their favorite one. And everyone benefits from that.


Well, no, let me explain.

Monads are all about types. They express what a function can do as a return type. As such monads are inherently tied to a language's type system. Since Python is weakly typed I'm not even sure you can use monads in it.

Java and C++ do have type systems but they're not great for Monads (compared to Haskell). On top of that, neither really care about avoiding side-effects. So even if you would have a monad, you have no guarantee that a function doesn't do all kind of stuff you didn't know/think about (other than going through the code). Even the Optional you mentioned just lets you throw with the get() method. Essentially, imperative languages just don't lend themselves well to the 'safety at type level' design philosophy of monads. If you want that safety, you'd be much better off with a pure language, of which the most popular is Haskell.

That said however, I don't think sticking with the language you already know is a very good idea, neither for your own career nor for the industry in general. Admittedly, Haskell has historically been a bit daunting to new arrivals (IMO, mostly due to its ecosystem and elitism in the community, not the language itself), which is the reason I recommended learning Elm instead.


You can avoid a lot of side-effects with C++'s const specifier. It also has more powerful type system than Java, to the extent of allowing higher kinded types via template construction. I read a bit about that topic but it's still too abstract for me to grasp. At least, Optional has a clear use case and I actually used it a lot in my recent project. I think real world examples of problems that can be elegantly solved with monads (as opposed to any imperative approach) would help a lot. Because I'm not interested in a language feature if I can't understand it without understanding the whole language first. If I decide to learn Haskell I'll learn about monads in the process anyway. I don't think Go fans would switch to C++ just because it has templates or exceptions; rather they'd like to learn how to implement them in Go.

As for Optional's .get() — true, that's an oversight in this class design. I'd prefer to only have .map(), .flatMap(), .isPresent() and .ifPresent() but who am I to judge. At least Sonar has a rule that highlights .get() without prior .isPresent() but I try not to use it at all.

So, yeah, maybe these languages don't support all the pureness of the functional ones, I still believe the core idea can be expressed so that people would find it useful right away. I'd love to see some monad examples aside from Optional and their implementation in a mainstream language. Maybe incomplete (if so, you may describe what exactly the language misses and why this is so important) but at least it would be approachable for regular developers, not category theory graduates.

Oh I fully agree you shouldn't need to know a lot of Haskell or category theory to get a basic understanding of monads. That's basically why I wrote this article with imperative programmers in mind.

I guess that due to the potential for side-effects, even in the standard library, java devs just never really took to monads. Nor would I: if I'm using monads, why would I use java? But I haven't used java in a long time so I'm not the best person to comment on this.

Optional - which is equivalent to Maybe btw - is a bit of an odd one out because it's primarily a useful data representation that happens to be a monad, much like arrays, lists, trees etc.

Well, that's the main problem: if you're using monads, you'd use a language that already supports them natively. That assumes you're already familiar with the language and surely know what monad is and how to use it. See, these concepts from FP are bit too abstract for imperative languages that are far more common. So it's a chicken and egg problem and unfortunately explaining monads in a functional language doesn't help to break this cycle.

I've always seen Haskell as a purely academic language. Not much known software is written in it that I can name right off the bat. Only xmonad perhaps. I don't think it's a coincidence that it's not widely used in solving practical problems. Can't tell anything about Elm, didn't see it. So, why would I want to write my own monad? What exact problem would I solve with it that I can't without? Just a real life example. Everywhere monads are explained on Maybe and yes, I know that Optional is more or less that. But other than that? Java also has streams since 8 and they feel monadic, like you can apply a function on Stream and get Stream in response. That's cool and I don't see why you need a functional language to do that.

Also, this article, despite explaining everything in Haskell again, was pretty informative. It has a lot of pictures without confusing analogies, totally recommend it. Unfortunately, it's yet again about Maybe.

Sounds like you've already got a feel for what's monadic and not :-)

Mind though that streams can only be monadic is they are finite: an infinite stream of infinite streams is a higher-order infinity (∞2) which mathematically cannot be mapped to infinity, so no chance for a flatten function. Neither can you 'follow up' on infinity (andThen or bind), ergo not a monad.

code of conduct - report abuse