5 ms·

There's a bigger issue: using computational and mathematical complexity that is confusing to large swaths of mere mortal coders. This is sadly why languages, t

There's a bigger issue: using computational and mathematical complexity that is confusing to large swaths of mere mortal coders. This is sadly why languages, to pick on some easy target religions like PHP and so on have proliferated. Sure it's possible to reduce LoC and look clever with ever more complex representations of computational structures, but it's another thing to write supportable code that's straightforward to debug, improve and maintain. If someone wants to use a "research" language in production and/or want perpetual job security, there are plenty of languages for those requirements too. (There's never a perfect Turing power language for anything, only better fits than others. Clarity for a new-hire reader should be most valued goal after functionality.)

noelwelsh 12y ago
A monad is just a code pattern. If you try to program in a style that minimises mutate state you'll probably end up inventing something like a monad. Heck, jQuery is almost a monad -- it's not a true monad but it is similar in concept. Monads are not a big deal. Indeed they are so much of a not big deal that I expect this is a big part of the problem learning monads. People expect them to be something difficult and exotic, and go looking for hidden depths where there aren't any. I know I did when I first learned them. Eventually you break through and realise there is no hidden mystery. It's just a data type with a few functions, and they happen to be usable in a wide variety of contexts. That's what this blog post is trying to explain. Finally, you can teach monads to new hires in a very short period of time. We do in our training courses.
- phamilton 12y ago
  I like this post because it describes specific monads and why they are useful. If I were to recommend a basic path to understanding monads, I'd say do this: 1. Understand `map` in the context of lists. This can be done in Ruby or Scala very easily if you don't want to get into Haskell directly. 2. Learn about the Maybe monad (or Option in scala). Understand what mapping an Option or a Maybe means. A simplified explanation is to compare it to a list of either length 1 or 0. 3. Learn about the IO monad in Haskell. Understand how IO monads can compose. At this point, it's ok to just say magic happens and the compiler then cause a single IO monad (the result of composing multiple IO monads) assigned to main to execute and the side effects will happen. At that point, you've got a general understanding of how to use monads. It will actually take you pretty far. One key point that might be a hangup is going from `map` meaning "apply this function to every element and return a new list of the results" to `>>=` meaning "apply this function as dictated by the monad and return the result". It's probably good enough to acknowledge that `map` is a simplified case of `>>=`. In any case, as the linked article says here, you should be able to understand specific Monads fairly quickly. Perhaps truly understanding monads means knowing when to create new monadic structures but that's hardly a prerequisite to being productive with monads.
  - dllthomas 12y ago
    I think your description here is likely to be tremendously confusing, and I don't recommend anyone who doesn't already grok functors and monads read it...
    - phamilton 12y ago
      My point is that you can actively use Lists and Options in Scala and be using monads without having any idea what a functor or monad is. I believe that's a similar point to the article. It's easier to understand how to use specific monads than to understand the mathematical definitions of functors and monads. Knowing `fmap` is essentially distributive isn't necessary to use functors and get a feel for what they provide.
      - dllthomas 12y ago
        I understood your point. I think you were unclear about what behavior belongs to monad, in a way that will confuse newcomers. "map" (or "fmap") belongs to Functor; monads have it because they are functors. I agree that starting with the laws doesn't necessarily makes the most sense, and that they're not necessary (though can be valuable) for use of these things... but you do need to introduce the laws early enough that they're understood by the time someone goes to write their own instances of the relevant typeclasses - otherwise they're going to get bit by something that assumes the laws hold, and they're not going to understand why.
  - vertex-four 12y ago
    Haskell's IO monad is decidedly not useful outside the context of Haskell and pure functional programming, both of which I do not find fun. Are monads in general useful outside that context - for example, in mostly-imperative languages like Rust?
    - olavk 12y ago
      The IO and State monads is specifically to solve the problem of side effects in a purely functional language, so they are not really relevant in other languages. But other uses of monads, like say monadic parsers could be useful in other languages. And list comprehensions is also based on a monad in Haskell - this functionality is clearly useful in many other languages. But without some kind of syntactic sugar (like do-notation in Haskell) the use of monads becomes far to cumbersome, and it ends up being easier to solve the same problem in an ad-hoc manner.
- psibi 12y ago
  > jQuery is almost a monad Curious to know how as I have seen lots of people claiming jQuery to be Monad ? jQuery neither has any laws to govern it nor it has bind or inject interface.
- fubarred 12y ago
  Yup, people will still ask "WTF are monads?" just like they'll soon ask "WTF are (combinators|arrows|...)?", and there will inevitably be more tutorials, as per [0]. :) It's clarity of explanation that makes anything teachable &| learnable. [0] https://www.youtube.com/watch?v=xKRndVoo2ms https://www.youtube.com/watch?v=xKRndVoo2ms All signs of superhuman nature appear in man as illness or insanity. ~ Nietzsche
- olavk 12y ago
  I think it is more confusing than enlightening to claim that jQuery is 'almost' a monad.
ericelliott 12y ago
This is a terrible argument. I agree with the sentiment that code should be easy to read and debug for mere "mortals", but functional programming can radically simplify the process of understanding programs in many ways. Don't fear the monad! See: https://medium.com/javascript-scene/the-two-pillars-of-javascript-pt-2-functional-programming-a63aa53a41a4 https://medium.com/javascript-scene/the-two-pillars-of-javas...
chriswarbo 12y ago
There are different types of complexity. Whilst it's easy to see what a simple line of code is doing, it's not necessarily easy to see why it's being done, or to understand how a codebase made of simple lines works. An extreme example of this is machine code, where every instruction is incredibly simple, but trying to work out what the whole thing's doing in order to debug it can be very hard. As a mere mortal, I appreciate monads and the simplicity they bring to my code.

noelwelsh 12y ago

A monad is just a code pattern. If you try to program in a style that minimises mutate state you'll probably end up inventing something like a monad. Heck, jQuery is almost a monad -- it's not a true monad but it is similar in concept. Monads are not a big deal. Indeed they are so much of a not big deal that I expect this is a big part of the problem learning monads. People expect them to be something difficult and exotic, and go looking for hidden depths where there aren't any. I know I did when I first learned them. Eventually you break through and realise there is no hidden mystery. It's just a data type with a few functions, and they happen to be usable in a wide variety of contexts. That's what this blog post is trying to explain. Finally, you can teach monads to new hires in a very short period of time. We do in our training courses.

phamilton 12y ago
I like this post because it describes specific monads and why they are useful. If I were to recommend a basic path to understanding monads, I'd say do this: 1. Understand `map` in the context of lists. This can be done in Ruby or Scala very easily if you don't want to get into Haskell directly. 2. Learn about the Maybe monad (or Option in scala). Understand what mapping an Option or a Maybe means. A simplified explanation is to compare it to a list of either length 1 or 0. 3. Learn about the IO monad in Haskell. Understand how IO monads can compose. At this point, it's ok to just say magic happens and the compiler then cause a single IO monad (the result of composing multiple IO monads) assigned to main to execute and the side effects will happen. At that point, you've got a general understanding of how to use monads. It will actually take you pretty far. One key point that might be a hangup is going from `map` meaning "apply this function to every element and return a new list of the results" to `>>=` meaning "apply this function as dictated by the monad and return the result". It's probably good enough to acknowledge that `map` is a simplified case of `>>=`. In any case, as the linked article says here, you should be able to understand specific Monads fairly quickly. Perhaps truly understanding monads means knowing when to create new monadic structures but that's hardly a prerequisite to being productive with monads.
- dllthomas 12y ago
  I think your description here is likely to be tremendously confusing, and I don't recommend anyone who doesn't already grok functors and monads read it...
  - phamilton 12y ago
    My point is that you can actively use Lists and Options in Scala and be using monads without having any idea what a functor or monad is. I believe that's a similar point to the article. It's easier to understand how to use specific monads than to understand the mathematical definitions of functors and monads. Knowing `fmap` is essentially distributive isn't necessary to use functors and get a feel for what they provide.
    - dllthomas 12y ago
      I understood your point. I think you were unclear about what behavior belongs to monad, in a way that will confuse newcomers. "map" (or "fmap") belongs to Functor; monads have it because they are functors. I agree that starting with the laws doesn't necessarily makes the most sense, and that they're not necessary (though can be valuable) for use of these things... but you do need to introduce the laws early enough that they're understood by the time someone goes to write their own instances of the relevant typeclasses - otherwise they're going to get bit by something that assumes the laws hold, and they're not going to understand why.
- vertex-four 12y ago
  Haskell's IO monad is decidedly not useful outside the context of Haskell and pure functional programming, both of which I do not find fun. Are monads in general useful outside that context - for example, in mostly-imperative languages like Rust?
  - olavk 12y ago
    The IO and State monads is specifically to solve the problem of side effects in a purely functional language, so they are not really relevant in other languages. But other uses of monads, like say monadic parsers could be useful in other languages. And list comprehensions is also based on a monad in Haskell - this functionality is clearly useful in many other languages. But without some kind of syntactic sugar (like do-notation in Haskell) the use of monads becomes far to cumbersome, and it ends up being easier to solve the same problem in an ad-hoc manner.
psibi 12y ago
> jQuery is almost a monad Curious to know how as I have seen lots of people claiming jQuery to be Monad ? jQuery neither has any laws to govern it nor it has bind or inject interface.
fubarred 12y ago
Yup, people will still ask "WTF are monads?" just like they'll soon ask "WTF are (combinators|arrows|...)?", and there will inevitably be more tutorials, as per [0]. :) It's clarity of explanation that makes anything teachable &| learnable. [0] https://www.youtube.com/watch?v=xKRndVoo2ms https://www.youtube.com/watch?v=xKRndVoo2ms All signs of superhuman nature appear in man as illness or insanity. ~ Nietzsche
olavk 12y ago
I think it is more confusing than enlightening to claim that jQuery is 'almost' a monad.

ericelliott 12y ago

This is a terrible argument. I agree with the sentiment that code should be easy to read and debug for mere "mortals", but functional programming can radically simplify the process of understanding programs in many ways. Don't fear the monad! See: https://medium.com/javascript-scene/the-two-pillars-of-javascript-pt-2-functional-programming-a63aa53a41a4 https://medium.com/javascript-scene/the-two-pillars-of-javas...

chriswarbo 12y ago

There are different types of complexity. Whilst it's easy to see what a simple line of code is doing, it's not necessarily easy to see why it's being done, or to understand how a codebase made of simple lines works. An extreme example of this is machine code, where every instruction is incredibly simple, but trying to work out what the whole thing's doing in order to debug it can be very hard. As a mere mortal, I appreciate monads and the simplicity they bring to my code.