Comment by nine_k | Hacker News Reader

Comment by nine_k | Hacker News Reader

Parent Full thread

These words are merely unfamiliar. Do you think that 'pointer arithmetic', or 'open-closed principle', or 'abstract class', or 'exception propagation' sound less intimidating for a layman? But in reality none of these are complex after you've put a small effort to comprehend the notions behind them.

Specifically, try reading these completely un-academic un-papers.

'Either' monad, with nice kid-friendly pictures: http://fsharpforfunandprofit.com/posts/recipe-part2/

Bonus: Martin Fowler, of all men, endorses the above approach, in Java, of all languages: http://martinfowler.com/articles/replaceThrowWithNotificatio...

A Kleisli category, with examples in down-to-earth, compact, un-hairy C++: http://bartoszmilewski.com/2014/12/23/kleisli-categories/

This stuff is not hard and is utterly practical. It can very well be used in current industrial languages.

The worst service you can render to yourself is to start thinking that you already know all what is worth knowing, and close your mind to new concepts. Guys that thought that Fortran and Cobol are enough to get by for foreseeable future were technically correct — both are still in some demand! Unfortunately, their market share has dramatically shrunk, deservedly, as have employment opportunities.

I've been trying to get my mind around this kind of stuff for maybe a year. And I have to say that monads don't look like the solution to any of the problems that I actually face or have ever faced, in a thirty-year career.

So, no, it's not just that the words are unfamiliar. It's that the problems that they're trying to solve are so abstract that they're completely disconnected from the work that I actually do.

And before you tell me that I'm really doing this stuff without realizing it: Maybe so. That doesn't mean that my life would be improved by doing it explicitly.

It seems to me that the "everything is category theory" approach has the same over-abstraction problem that the Java "AbstractFactoryFactoryFactory" approach has, and deserves to be as frequently mocked.

When I found out about monads it was after I'd already implemented the same abstraction. It actually comes up quite a lot (async calls, error handling, audit logging, database access). http://m50d.github.io/2013/01/16/generic-contexts.html . Just like when I was told about "the visitor pattern", my reaction was mostly "that? I've been doing that for years. So that's what it's called".

Still, it's worth knowing the name for a concept so that you can talk to people about it, and it's certainly worth knowing the library tools that exist and can save you time. Pretty often I'll write two or three lines of code, look at it, and then realise "oh, that's just traverseM" or some such. Even if it doesn't save me any time writing, replacing three lines with one library call is a huge bonus to maintainability.

If you give some examples of the work that you do perhaps we can make some of the abstractions concrete.

Perhaps you could. That's not the same as making them useful for me, though.

I work primarily in embedded systems, where sequence is critical, many things are stateful, and there are multiple threads of control. So, for example, I could take the sequential aspects and re-write them as a monad. Or I could just do nothing, and let them be sequential imperative code.

I know that in a pure functional world, sequence can be written as a monad. But why should I care? In my world, it does nothing for me. I'm not going to try to write imperative code in a monad to build an illusion of non-sequential purity when the essence of what I need to be doing is so sequential.

The purity is not an illusion though. Writing those sequences as a monad gives you the ability to compose actions, creating a new sequence from code you've already written for one.

But that's not a net win for me, compared to just having the action in a function that is called from several places.

Worse, composing the actions means I have to think through how the composing is going to affect the sequencing of events. Just having a function doesn't give me that problem - the sequencing is explicit, not hidden, and therefore is easier to reason about.

Can you give me some example code? I think our discussion would be a lot more productive and mutually beneficial with some code examples/output.

I can't give actual example code (proprietary, company confidential, blah blah blah). So I'm going to have to come up with some fake example.

[Thinking...]

How about a robotic hand that's supposed to pick up a ball. The (C/C++) code might look like :

  void pickUpBall()
  {
    openHand();
    moveHandToBall();
    closeHand();
  }

You have to have that sequence. If the hand isn't open, moving it to the ball just bumps the ball away. If you close the hand before you move to the ball, you don't pick up the ball, you just close on air.

So, in Haskell (if I had the hardware control libraries), I could put that in a monad to guarantee the sequence, and in an IO monad so that I could do things that had side effects like affecting the external world. But in fact I get both of those for free, just by not writing it in Haskell. (The pure functional nature of Haskell also doesn't do much for me in this situation. Yes, for the functions that can in fact be purely functional, it can make them easier to reason about and prove correct. But that isn't the difficult part of the code.)

Composability: It's unclear to me how you're going to compose something like this in any way that's a) useful in this environment and b) dramatically different from simply making a higher-level function that calls pickUpBall() and some other functions.

Cool, now we have something to work with. However at such a high level no paradigm's differences (much less pros/cons) would be apparent. Would you mind implementing those individual functions?

Actually it might be easier to use some open source embedded code.

For completeness sake, I'd write the snippet above almost identically:

    pickUpBall = do
        openHand
        moveHandToBall
        closeHand

OK, now you've got me really confused. Is that Haskell code? I thought that Haskell couldn't do sequence except inside a monad. (Or is "do" a monad?)

But if that isn't a monad, then why did you write it that way? My original claim was that a monad wouldn't do much for me in my world, and if you wrote this without a monad, that kind of seems like you're agreeing with me.

You said that you'd gain composability from writing this as a monad. In this example, how would that work? What would it buy me that I couldn't write (as easily) using what to me is the normal way?

It would most likely be in the IO monad since IO would be happening.

As for whether monads would help your code (and I still think they would) I'll need a larger example. In a small example abstraction and reuse aren't really apparent.

If you can provide a larger example, we can find out who's right ;)

Alternatively I'll try to find a larger example if you can't or don't want to.

Well, I just made up this example, so feel free to embellish it...

But as you do, remember the question. We're in an embedded system, with lots of situations where sequence matters, and lots of stored state. The question is, what do monads buy me in that environment?

One neat thing you can do with monads thats useful in your setting is coroutines/generators as a library. You get to write code that looks like its regular sequential code and behind the scenes it gets expanded into the "callback hell" you would have had to write if you decided to code the things in event driven style by hand.

Anyway, I do have to say that the Monad abstraction is not that useful outside of Haskell because you kinda really need Type Classes to get monads "right" and most languages don't have that. What you might end up is with specific monads like promises in JS but then the monads are just a design pattern instead of being a concrete abstraction like they are in Haskell.

In addition to that, in Haskell monads are the only way to do sequential computations with side effects because by default the language is Lazy. This means that Haskell programmers have to learn this abstraction whether they like it or not while in other languages you can avoid it better :)

Did you ever work with a list? Did you ever do things like

   foo = [bar(x) for x in quux]

Or did you ever flatten a nested list?

Congratulations, you've been using one of the most widespread monads.

Monads are not artificial constructs. Monads, like functions, or loops, or conditional statements, emerge naturally when you try to describe a computation, even a simple one. This is like speaking prose without knowing that.

No, actually, I don't do things like that (see my parallel reply to codygman).

The Haskell types often seem to think that the computing they do is the same as the computing that everybody else does, and therefore that the problems that they want to solve are the ones that everybody else wants to solve. That's not a very accurate assumption.

Just for reference: what are the kinds of problems you solve?

Note that the code I quoted above is Python, and I have lots of stuff like that in my mundane production code (processing files, tracking transactions, counting money, etc).

> The Haskell types often seem to think that the computing they do is the same as the computing that everybody else does

Seeing as Haskell is used for general computing (including embedded software) the computing is the same. I know what you ate getting at, but I don't think it is based on facts or anything rational.

    foo = [bar(x) for x in quux]

This is effectively a map, so it's strange to call it "using monads". "Using functors" would be more accurate.

You can get "monad" out of list comprehensions though, when you have multiple "for" clauses.

    foo = [y for x in quux for y in bar(x)]

seems equivalent to foo = quux >>= bar

Reply on news.ycombinator.com