Hacker News Reader

Comment by andrewprock | Hacker News Reader

I don't get it either. These are probably toy examples written to motivate a specific solution. Note that the semantics change between versions. In some versions, erroring out will not print anything, in others it will.

If this is Java, why not use exceptions, or @NonNull. If this is C++, why not use exceptions?

I'll note that for loops and if statements are fundamental constructs that many people don't really understand. I've seen a lot of bad code written with if statements and for loops. If these fundamental constructs can be misused to create bad code, how much likely is it that more abstract constructs like list comprehensions, futures, and monads will be used to create bad code?

View on HN

> Note that the semantics change between versions.

Because each one describes a different type's implementation of the monad interface. The blog post is just trying to illustrate:

"all these problems have the same interface. If we have a general solution to a problem, why use a different ad hoc solution for each?"

I think something was missed, and maybe I missed it. It looks to me like this:

    var a = getData();
    if (a != null) {
      var b = getMoreData(a);
      if (b != null) {
         var c = getMoreData(b);
         if (c != null) {
            var d = getEvenMoreData(a, c)
            if (d != null) {
              print(d);
            }
         }
      }
    }

will only print on non-null, whereas this:

    do
      a <- getData
      b <- getMoreData a
      c <- getMoreData b
      d <- getEvenMoreData a c
      print d

will always print something.

It won't. If any of the functions on the right-hand side of the '<-' return Nothing, then the later lines do nothing. Think of the '<-' operator as a 'flatMap' call for Optionals in Java, if you are more familiar with that.

This particular syntax for chaining together monads is called 'do notation', and is just syntax sugar for calling the bind function (flatMap in Java) manually.

>will always print something.

Not necessarily. It depends on which monad is being used here (the article doesn't specify). If you replace the 'print' with 'return' to simplify things, then this could be an expression in the Maybe monad, which would return either (Just d) or Nothing.

The article is lying a bit by suggesting that it's trivial to layer short-circuit-on-error behavior on top of the IO monad. It's possible for sure, but some relatively subtle issues can arise (in Haskell at least).

This is what I always hated with C++, and to a lesser extent Java. The code that you cannot see makes it very difficult to understand the code when reading the source. If the only person that can truly understand the code is the author, that is an anti-pattern.

The for loops and if statements were never a problem, it was the default constructors, overloaded operators, and the like that always caused confusion on my teams.

In simple cases you'd be able to see the concrete type if this were real Haskell code, so you'd know which monad instance was the relevant one. Your complaint does apply to some uses of the monad transformer library, however.

The two blocks of code are exactly equivalent, the "if != null" logic is moved into the <-.

And the first snipped is purposely badly written. One can use early returns to make code flat just like the monadic example.

Sure, you can flatten that example, but I'd still be interested in losing the explicit and repetitive null checks.

In the old days, we used #define macros to do that.

"If these fundamental constructs can be misused to create bad code, how much likely is it that more abstract constructs like list comprehensions, futures, and monads will be used to create bad code?"

If your developers are consistently writing bad code, fire the developers. They will write bad code in any and every language.

Assuming people are always getting better yet always producing. Things are and always will be short of the ideal.

Reply on news.ycombinator.com