I agree that Haskell is built around those concepts. But the point of learning category theory is to change your mindset when programming. And even in Javascript, it is super useful. (basically because, while trying to learn category theory, you become fluent in functional programming ).

>Part 3 will start to dance the fine line between practical programming and academic absurdity. We'll look at comonads, f-algebras, free monads, yoneda, and other categorical constructs.

I myself like this - https://github.com/valentjedi/ddd-dynamic - but I'm beginning to think maybe all of this is not the right paradigm for programming in languages like javascript or python. The success of tools like React or RxJava in Android makes me think that the tools define the paradigm and not the other way around... no matter how much we want it to be.

I thought the original Rx was a Haskeller saying "Hey a 'dsl' built on a monad would be really powerful here in C#" and implemented it. Then it spread to other langs from there.

In my opinion the biggest hurdle is the fact that getting to unrestand purely functional programming is pretty difficult. You start with monads, but quickly find out they do not compose. Move on to monad transformers, good for the simple stuff, but then you hit another wall because they don't compose either! Move on (up!) to tagless final and/or free monads. There are _a lot of_ concepts that don't have any equivalent in "the real world". The gang of four design patters are a child's toy in comparison.

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

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

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

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

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

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.

Huh? List is very much a monad.

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]

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

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

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

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

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

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!

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.

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

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"]

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

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

Besides, I don't think you would gain anything by using CT concepts in a language that won't resolve type polymorphism for you. It will lead to a mess of a code, where you'll have to make everything explicit.

By the way, great language. an await command in a where scope is just phenomenal. Between seamless lambdas, interdependent functional declarations, and forced async I don't think it missed any language at its trolling.

There's a lot more to accessibility than how easy the syntax is to grok. This is just one simple and limited example.

Yet there are a ton of books written about Lisp in all kinds of topics and applications. Not to mention really well-written tutorials like "Practical Common Lisp".

Plus, the documentation/reference of the language itself is comprehensive and well written, comparing favorably to the documentation for most programming languages out there.

You are using one right now: Hacker News is written on a Lisp: Arc.

Also, the first HTTP 1.1 compliant server and used by the W3C to debug the HTTP 1.1 reference implementation, was written in Common Lisp.

Exactly.

Or, the IDE can close all the parens for you: SLIME command "slime-close-all-parens-in-sexp", which you can map to whatever key combination you want.

I picture the difference as that between a role playing game and chess: complex, domain-specific rules on one side, simple and abstract rules on the other.