4 ms·

I don't get it. The article doesn't explain anything. It's just a list of statements. "This is bad, that is good." But it doesn't explain why the bad things are

• andrewprock 9y ago
  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 <-.
  • 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.
• dragonwriter 9y ago
  > The article doesn't explain anything. Sure it does, it provides a pragmatic rather than abstract answer to the question “what are monads”. > It's just a list of statements. "This is bad, that is good." But it doesn't explain why the bad things are bad, and how using monads is better. As I see it, that's because it's based on targeting an audience in which: (1) it is widely accepted that the “Hell” things are bad, and (2) it is widely accepted that simple, general solutions to broad classes of problems are better than myriad special solutions to narrow subsets. > It also doesn't explain what monads are. Not in the abstract sense; otoh, the whole piece is a pragmatic explanation of what monads are: the common solution to an array of problems for which a series of examples is provided.
  • rattray 9y ago
    Hmm, if I had to guess, I'd say you were in the camp of people who already "got" Monads...
    • dragonwriter 9y ago
      > Hmm, if I had to guess, I'd say you were in the camp of people who already "got" Monads... On the level the article seeks to explain? Yes, sure. On the abstract level lots of other monad resources try to convey? Not particularly.
• jimbokun 9y ago
  "My guess is that all the people praising this article already "got monads"." You are correct. This is an advocacy piece for using Monads to solve common programming problems. However, I believe this article can still be useful for people who do not yet "get monads". Much of the prose written on Monads never bothers to first address "Why should I care? What problem that I already have can Monads help me solve?" This shows multiple concrete examples where Monads can improve code clarity and readability. So now you can make an informed decision about whether you want to learn more. Of course, if you dislike code clarity (and many programmers fall into this category), then Monads may not be right for you.