He means that there's no type syntax to assist with monad creation or usage which indicates a sort of incomplete understanding of the concept.

As an example, a maybe monad in python can be implemented by having a monadic function return either:

  ["Just", 1]
  ["Nothing", None] 

and the bind operator (>>=) would be:

  bind = lambda a, f: a if a[0] == "Nothing" else f(a[1])

You should also understand that a list itself can be a monad. Monads are just burritos where ANY abstraction/design pattern can be the wrapping, it does not need a haskell type system to wrap something. Albeit the type system in haskell does really help you grok the concept.

Weirdly how someone chooses to implement a monadic value and the bind operator suffers from the same problem as what this article writer complains about in OOP design patterns. Both monads and design patterns really depend on previous understanding of a pattern, and a variation on how someone chooses to implement the bind operator or a design pattern can really throw off people.

Here is an example of an alternative variation of the "Maybe" monad in python, for the return values:

  ["Only", 1], None

And a variation on bind:

  bind = lambda a, f: f(a[1]) if a is not None else None

> You should also understand that a list itself can be a monad.

A list is not a monad — it’s just a container of values, ie. a functor. A monad is a data structure defines a computation in a specific context, and allows composing these in a sequential manner. For example, the Haskell IO monad is a computational context in which you can do input/output, and all of these IO operations are represented using a data structure of the type “IO <return_value>”.

For example, the function “readLine” has the type “IO String”, and represents a computation that reads a line from standard input and returns it as a string. At runtime, evaluating this value will result in the runtime system asking the user for some input, and at compile-time this is represented as the string (that the user enters at runtime) inside the IO monad.

> A list is not a monad

Huh? List is very much a monad.

You're completely right. I had no idea.

But I can't make sense of the definition of >>= for the list in Haskell, which is:

    xs >>= f = [y | x <- xs, y <- f x]

It seems to imply that I get a list in return when I do xs >>= f, but I need to do the following in order for it to work:

    [1,2,3] >>= return . (+1)

You're probably use to Monads that wrap a single object, like the maybe monad. Monads can wrap multiple objects or anything. This is the case for a list.

Perhaps this might help (or perhaps not!)

    > [1,-2,3] >>= (\x -> replicate (abs x) x)
    [1,-2,-2,3,3,3]

this is a super interesting reply - you kind of translated these monadic concepts to python.

Is there a resource for this ? or good old intuition ?

Nah no single resource, it took me a lot of time to understand monads, going over many resources.

Just remember Absolutely ANY design pattern / data structure can be a monad as long as you can get an internal value out of that abstraction and define a bind operator to compose monads together.

This rule tells it all:

  (>>=)            :: m a -> (a -> m b) -> m b

m is the abstraction wrapper and a is the internal thing that is wrapped. You can wrap it in a type string, a list. Even like a binary tree can be a monad.

You can define the bind operator to do whatever you want, it just needs to follow the type signature above and be associative.

Oh and nothing was translated. A monad is a general concept applicable to almost any language. Deep understanding of a monad is to understand it outside of the haskell ecosystem.

genuine question - can this be done in python in a production ready manner ?

I'm have been trying to answer this question for quite some time. In Haskell, writing monads or applying category theory is part of the idiomatic language. Not so in js or python.

for example, if you want to apply haskell like concepts in javascript, the closest thing I know is purescript (http://www.purescript.org/) or Bucklescript. So you need to switch over to a different language to achieve the richness of these concepts.

I'm hardpressed to apply these concepts idiomatically to the mainstream languages. Compare this to design patterns or OO, or reactive programming (via rxjs or whatever) - which are so accessible that they are now the reason to learn a particular language!

> genuine question - can this be done in python in a production ready manner ?

It can, but without a type system you lose most of the benefits. You can put monads in there but if you refactor fearlessly the way you would in Haskell (without tests), you'll get production bugs.

> Compare this to design patterns or OO, or reactive programming (via rxjs or whatever) - which are so accessible that they are now the reason to learn a particular language!

Isn't that the same thing? Monads etc. are the reason to learn Haskell.

Wrt your question about production-ready manner: I don't know.

However, there are many libraries which make functional programming in Python seem viable. See eg: https://pypi.python.org/pypi/PyMonad/

Functional programming is just imperative programming with heavy heavy restrictions. So yes this can be done, as long as you fully understand what functional programming really is...

A functional program is simply a program that is made up of a single mathematical expression. Complexity is achieved in functional programming by composing smaller expressions into a single big expression. It should be possible to write your entire functional program as a single expression or statement (not saying you should do it, but it should be possible). That's it. That means all your python functions should be a single expression only (use lambda always instead of def; or if you must use def make sure all your variables remain immuted)

If you want to apply like category theory to it, then just make sure your python functions always stick to specific types. Don't let a function take in either a string or an int and return a list or a iterator or any bullshit like that. Keep the typing consistent... If you define all your functions to behave mathematically like only taking in a string and only returning an int, not an int or a None... then you are following category theory.

So nothing like this:

  def someFunc(value):
     if value == "hello"
        return 1
     elif value == 123:
        return [1,"world"]

or this:

  blah = lambda a: "hello" if a is None else 304

If you wanted automated type checking at run time you can use a decorator to check the types of variables going into the function and coming out.

If you try this style at work, people will complain haha, I don't recommend it