3 ms·

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 i

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

by lubutu 15y ago

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.