Hacker News Reader

Comment by jazzypants | Hacker News Reader

> I won’t fall into the trap of trying to define Monads in this post. Instead, let’s talk about monadic-style APIs – that is, APIs that allow you to do a bunch of things one after another, with the ability to use the result of a previous computation in the next computation, and also allows some logic to happen between steps.

Am I crazy, or did he just give a really good definition of monads in programming? I think that it benefits by not letting itself get bogged down in Category Theory nomenclature which doesn't actually matter when programming.

View on HN

He described a problem people use monads to solve, not monads themselves.

Haskell people do talk about monadic vs. applicative combinators that are different by whether you can use the results of a previous step on the next ones. But that doesn't have a direct relation with the actual definition of those.

But yes, if you are teaching a programming language that uses monads to someone, you will probably want to explain the problem they solve, not the actual structures. As most things in math, the structures become obvious once you understand the problem.

It's a good description of one application of monads, which is often helpful to beginners if they have been thrown into real code without yet understanding the "why" of monads. If you look up "railway-oriented programming," you'll find more presentations of it.

I think it is a very practical place to start, especially for programmers who have been thrown into a codebase while still new with monads, because it helps them avoid a common mistake that plagues beginners: accidentally dropping error values on the non-success track. Often you simply want to drop values on the non-success track, and there are convenient idioms for doing so, but just as often, you need to examine those values so you can report failures, by returning metrics on validation failures, by providing the right status code in an HTTP response, etc. Railway-oriented programming is a vivid metaphor that reminds programmers that they need to make a decision about how to handle values on the other track.

No, this isn’t a good description of monads. It merely describes a case that shows up sometimes.

Dang, when I made this silly, little comment about FP, I didn't expect to get corrected by a legend in the field!

Thanks for taking the time to respond.

A monad is just a monoid in the category of endofunctors, what's the problem?

Yin the OOP world I’ve seen this pattern called chaining : usually either method or object chaining.

It's a style I really enjoy, and it's definitely not exclusive to one language or paradigm, exactly. I see it as more of less of a kind with pipelines in Unix shells, too.

In Scala, a language with OOP heritage and support, plus lots of functional programming features, some of the most common methods you use in such chains are monads.

Smalltalk (and Dart) also have "cascading" which is method chaining with special supporting syntax e.g. in ST you'd send four different messages to the same object with something like

    scene add: sprite; 
          add: otherSprite;
          setBackGround: stage;
          start

I'm not sure if it matches the "reuse values from previous computation" but it should since messages will affect the object, you just don't have local variables.

It is using ';' instead of parenthesizing the messages to the objects, correct?

In Smalltalk, `;` does two things: terminates the current message (EDIT: while ignoring its return value) and propagates the target object of the current message as a target for the following message.

So this:

    scene add: sprite; 
          add: otherSprite;
          setBackGround: stage;
          start

is equivalent to:

    scene add: sprite.
    scene add: otherSprite.
    scene setBackGround: stage.
    scene start.

In Dart, they use `..` prefix instead of `;` postfix: https://dart.dev/language/operators#cascade-notation

    var paint = Paint()
      ..color = Colors.black
      ..strokeCap = StrokeCap.round
      ..strokeWidth = 5.0;

You can model this with monads easily, but it's just one, very limited application of them - monads are much more general.

visual basic has the `with` statement for that https://learn.microsoft.com/en-us/dotnet/visual-basic/langua...

Nim has a similar `with` for the same use case. It can be handy!

Not really. The big important part of monads is flattening/unnesting the output.

Basically, if you can convert a `Foo<T>` into a `Foo<U>` by applying a function `T -> U`, it's a monoid. Think `map` or `fold`.

But if you can convert a `Foo<T>` into a `Foo<U>` by applying a function `T -> Foo<U>`, it's a monad. Flattening is "some logic", but not any logic, it's inherent to `Foo<>` itself.

Your point on unnesting is apt but don't you mean functor instead of monoid?

Yeah, you're right, I do. Thank you.

It's a good spit, some people used to describe them as "programmable semi colon" but while it's simple, it may be too short for most people to grasp.

I think you just fell into the trap.

Reply on news.ycombinator.com