6 ms·

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 version

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?

leshow 9y ago
> 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?"
- deleted 9y ago
  [deleted]
- andrewprock 9y ago
  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.
  - foldr 9y ago
    >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).
    - andrewprock 9y ago
      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.
      - foldr 9y ago
        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.
  - jhomedall 9y ago
    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.
  - vilhelm_s 9y ago
    The two blocks of code are exactly equivalent, the "if != null" logic is moved into the <-.
    - dullgiulio 9y ago
      And the first snipped is purposely badly written. One can use early returns to make code flat just like the monadic example.
      - mclehman 9y ago
        Sure, you can flatten that example, but I'd still be interested in losing the explicit and repetitive null checks.
        andrewprock 9y ago
        In the old days, we used #define macros to do that.
jimbokun 9y ago
"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.
- dlwdlw 9y ago
  Assuming people are always getting better yet always producing. Things are and always will be short of the ideal.

leshow 9y ago

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

deleted 9y ago
[deleted]
andrewprock 9y ago
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.
- foldr 9y ago
  >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).
  - andrewprock 9y ago
    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.
    - foldr 9y ago
      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.
- jhomedall 9y ago
  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.
- vilhelm_s 9y ago
  The two blocks of code are exactly equivalent, the "if != null" logic is moved into the <-.
  - dullgiulio 9y ago
    And the first snipped is purposely badly written. One can use early returns to make code flat just like the monadic example.
    - mclehman 9y ago
      Sure, you can flatten that example, but I'd still be interested in losing the explicit and repetitive null checks.
      - andrewprock 9y ago
        In the old days, we used #define macros to do that.

jimbokun 9y ago

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

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