5 ms·

I find the whole point of the article to be weak, to say the least. OK, I'm doing monads, or something equivalent to monads, all the time along my imperative co

by tcard 15y ago

I find the whole point of the article to be weak, to say the least. OK, I'm doing monads, or something equivalent to monads, all the time along my imperative code without even noticing because it's so intuitive concept. So when this common abstraction of "conditional function calls" is made explicit through monad syntax instead of intuitive-implicit, it is supposed to be easier to deal with? Perhaps it's cleaner, and you can get accustomed to it, but it surely comes with an overhead over imperative thinking, at least for a beginner.

lubutu 15y ago
It does come with an overhead for a beginner, to be sure. But because it is a consistent abstraction we can build idioms on top of the concept of a monad, and in doing so it actually becomes easier to reason about. The best things in life have a learning curve. Edit: Wow, I was downvoted for this?
- willvarfar 15y ago
  (not downvoter) I come to completely the opposite conclusion: http://williamedwardscoder.tumblr.com/post/18319031919/programming-language-readability http://williamedwardscoder.tumblr.com/post/18319031919/progr... There's nothing stopping someone writing a haskell-alike with readable syntax as long as they stay away from trying to create terms like monads to explain things that don't need explaining ;)
  - whateverer 15y ago
    Monads only need a lengthy explanation if you don't understand that they are a typeclass in Haskell. The monad laws you can take to be principles on which to correctly implement them, but they aren't necessary for their use. Besides, that whole post just gave me the impression that you haven't done the minimum necessary to understand Haskell programs. You claim that there is no immediate visual grouping of the expressions, yet you seem to gloss over all the pattern-based definitions of functions. Now, if you find using such lengthy sequences of patterns to define your functions unsavory, you can use case expressions, which... require indentation for their cases. On most respects, it just comes down to the fact that Haskell is different, and it takes a bit of reading to accustom oneself to it. edit: It was a tad too defensive before. Sorry 'bout that.
  - lubutu 15y ago
    I don't think that's a fair comparison. Here's a toy trie implementation I've just thrown together in Haskell. It may not be perfect, but I think it's more comparable to your Python. http://lubutu.com/media/temp/trie.hs http://lubutu.com/media/temp/trie.hs
  - JadeNB 15y ago
    > There's nothing stopping someone writing a haskell-alike with readable syntax as long as they stay away from trying to create terms like monads to explain things that don't need explaining ;) There's nothing stopping someone from doing that while trying to create such terms, either; witness Haskell. (Or maybe your argument is that the syntax isn't readable? Well, is `>>=` really worse than `?:` in terms of immediate apprehensibility?) However, I think it's important to recognise that the use of 'monad' is not a case of "creat[ing] terms … to explain things that don't need explaining". A pattern was identified, and it was realised that it fit into the existing mathematical formalism of monads (http://en.wikipedia.org/wiki/Monad_%28category_theory%29 http://en.wikipedia.org/wiki/Monad_%28category_theory%29). This can hardly be regarded as a willfully abstruse activity; identifying and naming existing patterns, especially if the name is already out there, is part of a (good) computer programmer's toolkit, right? http://en.wikipedia.org/wiki/Design_Patterns http://en.wikipedia.org/wiki/Design_Patterns
    - willvarfar 15y ago
      And python should be embarrassed how exactly?
      - JadeNB 15y ago
        I never said anything about embarrassment; I was just defending the virtue of using existing names to recognise pre-explored patterns, even if they frighten people.
danieldk 15y ago
It is not only cleaner, it is also safer. In Python you have to add checks explicitly, or your program may try to execute a method on None. When using the Maybe or Either monad in Haskell, failure is always handled. Say that you have a sequence of three functions that return a Maybe value: do b <- f a c <- g b h c Now, suppose that in a particular case f a returns Nothing, then the whole do-expression will evaluate to Nothing and g Nothing is never evaluated. Failure monads do not only add cleanliness, but also safety.
- icebraining 15y ago
  One could say the problem is using None for indicating errors. Python does have exceptions, which also prevent further statements from being executed. try: b = f(a) c = g(b) return h(c) If f(a) raises an exception, g and h don't get executed. None should be returned when it's a valid value (say, in search() if it doesn't find anything), and in those cases it makes sense to have explicit handling.
  - danieldk 15y ago
    That's a fair point. On some level a try block resembles a monad that encapsulates success/failure. However, it is not general, e.g. it does not provide a solution if you want to chain computations where returning None/Nothing is valid (e.g. a Map lookup in Haskell). The nice thing about monads is that it provides an abstraction on sequences of computations, involving failure, error, state, effects, etc. Though, it can get ugly at times when you want to use multiple monads simultaneously (via monad transformers).
    - icebraining 15y ago
      However, it is not general, e.g. it does not provide a solution if you want to chain computations where returning None/Nothing is valid (e.g. a Map lookup in Haskell). But I think that's a feature, not a bug. Conflating errors and valid values leads to ambiguity. As PEP 20 says, "Explicit it better than implicit". If you actually want certain function return values to act as a failure, I think you should wrap it in a new function that adds those semantics.
obtu 15y ago
It's a stumbling block the beginner must learn once, not really an overhead that comes up at every use.

by tcard 15y ago

lubutu 15y ago

It does come with an overhead for a beginner, to be sure. But because it is a consistent abstraction we can build idioms on top of the concept of a monad, and in doing so it actually becomes easier to reason about. The best things in life have a learning curve. Edit: Wow, I was downvoted for this?

willvarfar 15y ago
(not downvoter) I come to completely the opposite conclusion: http://williamedwardscoder.tumblr.com/post/18319031919/programming-language-readability http://williamedwardscoder.tumblr.com/post/18319031919/progr... There's nothing stopping someone writing a haskell-alike with readable syntax as long as they stay away from trying to create terms like monads to explain things that don't need explaining ;)
- whateverer 15y ago
  Monads only need a lengthy explanation if you don't understand that they are a typeclass in Haskell. The monad laws you can take to be principles on which to correctly implement them, but they aren't necessary for their use. Besides, that whole post just gave me the impression that you haven't done the minimum necessary to understand Haskell programs. You claim that there is no immediate visual grouping of the expressions, yet you seem to gloss over all the pattern-based definitions of functions. Now, if you find using such lengthy sequences of patterns to define your functions unsavory, you can use case expressions, which... require indentation for their cases. On most respects, it just comes down to the fact that Haskell is different, and it takes a bit of reading to accustom oneself to it. edit: It was a tad too defensive before. Sorry 'bout that.
- lubutu 15y ago
  I don't think that's a fair comparison. Here's a toy trie implementation I've just thrown together in Haskell. It may not be perfect, but I think it's more comparable to your Python. http://lubutu.com/media/temp/trie.hs http://lubutu.com/media/temp/trie.hs
- JadeNB 15y ago
  > There's nothing stopping someone writing a haskell-alike with readable syntax as long as they stay away from trying to create terms like monads to explain things that don't need explaining ;) There's nothing stopping someone from doing that while trying to create such terms, either; witness Haskell. (Or maybe your argument is that the syntax isn't readable? Well, is `>>=` really worse than `?:` in terms of immediate apprehensibility?) However, I think it's important to recognise that the use of 'monad' is not a case of "creat[ing] terms … to explain things that don't need explaining". A pattern was identified, and it was realised that it fit into the existing mathematical formalism of monads (http://en.wikipedia.org/wiki/Monad_%28category_theory%29 http://en.wikipedia.org/wiki/Monad_%28category_theory%29). This can hardly be regarded as a willfully abstruse activity; identifying and naming existing patterns, especially if the name is already out there, is part of a (good) computer programmer's toolkit, right? http://en.wikipedia.org/wiki/Design_Patterns http://en.wikipedia.org/wiki/Design_Patterns
  - willvarfar 15y ago
    And python should be embarrassed how exactly?
    - JadeNB 15y ago
      I never said anything about embarrassment; I was just defending the virtue of using existing names to recognise pre-explored patterns, even if they frighten people.

danieldk 15y ago

It is not only cleaner, it is also safer. In Python you have to add checks explicitly, or your program may try to execute a method on None. When using the Maybe or Either monad in Haskell, failure is always handled. Say that you have a sequence of three functions that return a Maybe value: do b <- f a c <- g b h c Now, suppose that in a particular case f a returns Nothing, then the whole do-expression will evaluate to Nothing and g Nothing is never evaluated. Failure monads do not only add cleanliness, but also safety.

icebraining 15y ago
One could say the problem is using None for indicating errors. Python does have exceptions, which also prevent further statements from being executed. try: b = f(a) c = g(b) return h(c) If f(a) raises an exception, g and h don't get executed. None should be returned when it's a valid value (say, in search() if it doesn't find anything), and in those cases it makes sense to have explicit handling.
- danieldk 15y ago
  That's a fair point. On some level a try block resembles a monad that encapsulates success/failure. However, it is not general, e.g. it does not provide a solution if you want to chain computations where returning None/Nothing is valid (e.g. a Map lookup in Haskell). The nice thing about monads is that it provides an abstraction on sequences of computations, involving failure, error, state, effects, etc. Though, it can get ugly at times when you want to use multiple monads simultaneously (via monad transformers).
  - icebraining 15y ago
    However, it is not general, e.g. it does not provide a solution if you want to chain computations where returning None/Nothing is valid (e.g. a Map lookup in Haskell). But I think that's a feature, not a bug. Conflating errors and valid values leads to ambiguity. As PEP 20 says, "Explicit it better than implicit". If you actually want certain function return values to act as a failure, I think you should wrap it in a new function that adds those semantics.

obtu 15y ago

It's a stumbling block the beginner must learn once, not really an overhead that comes up at every use.