4 ms·

It's code reuse for concepts. Wouldn't you agree that reusing intuition about things is good? It's the same as knowing what big-O is instead of just memorizing

It's code reuse for concepts. Wouldn't you agree that reusing intuition about things is good? It's the same as knowing what big-O is instead of just memorizing "bubble sort is slower than insertion sort, insertion sort is sometimes faster than quicksort but usually not", or knowing what concurrency is instead of memorizing the API of a library in your favorite language.

dmitriid 9y ago
The entire "concept" of a monad fits in that description I linked to. It can be easily reused (which I've done numerous times with it, and with other concepts on that page). Haskell for some reasons insists that I should only go for "The concept of a monad, which arises from category theory, has been applied by Moggi to structure the denotational semantics of programming languages" and A monad is a triple (M,unit,⋆) consisting of a type constructor M and two operations of the given polymorphic types. These operations must satisfy three laws given in Section 3. We will often write expressions in the form m ⋆ λa. n Should I? Really?
- mrkgnao 9y ago
  Yes, you should care about the laws! They allow you to edit code without the aforementioned released-last-week test runner having to check all your code after a big refactor. I mean, you can't call something with a "flatMap" method and a "return" method a monad! There are tons of nonsensical definitions that fit that which are going to become very unpleasant to use quickly.
  - dmitriid 9y ago
    > They allow you to edit code without the aforementioned released-last-week test runner having to check all your code after a big refactor. Oh wow. How did I ever live with big refactorings before? > There are tons of nonsensical definitions that fit that which are going to become very unpleasant to use quickly. I recently learned that, apparently, I've been using "monads" and "monadic composition" for years now, never knowing what it is. Can't remember any unpleasantness that would "quickly arise". There are other things than blind following after a Platonic ideal.
    - mrkgnao 9y ago
      The unpleasantness arises when writing Monad instances that don't follow the laws. Setting your disingenuity aside, try using xs >>= f = concat (reverse (map f xs)) or Array.prototype.chain = function (f) { return reverse(this.reduce((acc, it) => acc.concat(f(it)), [])) } (I don't know how JS works, but you get it) instead of xs >>= f = concat (map f xs) and enjoy refactoring your code, blissfully and consciously ignorant of the laws that make a monad a monad. The laws aren't just supposed to enrich the "life of the mind".
      - dmitriid 9y ago
        So, what problems will I experience while refactoring this code (if I ever wrote it)?
        mrkgnao 9y ago
        It won't satisfy the properties you've come to expect from the implementations you know for lists, optionals (Maybe), and so on. Suppose you're going over some code, where you have something of the form xs >>= someFunction (where xs is a list) and you change someFunction to "return": xs >>= return Then you'd expect, from experience, that you can rewrite this to just xs (which you can check works with all the monads you know about) but that doesn't hold for this wonky definition of the Monad instance for lists. Indeed, note that return for lists has the definition return x = [x] so, with our bad >>=, [1, 2, 3] >>= return = concat (reverse (map (\x -> [x]) [1, 2, 3])) = concat (reverse ([[1], [2], [3]])) = concat [[3], [2], [1]] = [3, 2, 1] which is not the same as [1, 2, 3]. https://wiki.haskell.org/Monad_laws https://wiki.haskell.org/Monad_laws

dmitriid 9y ago

The entire "concept" of a monad fits in that description I linked to. It can be easily reused (which I've done numerous times with it, and with other concepts on that page). Haskell for some reasons insists that I should only go for "The concept of a monad, which arises from category theory, has been applied by Moggi to structure the denotational semantics of programming languages" and A monad is a triple (M,unit,⋆) consisting of a type constructor M and two operations of the given polymorphic types. These operations must satisfy three laws given in Section 3. We will often write expressions in the form m ⋆ λa. n Should I? Really?

mrkgnao 9y ago
Yes, you should care about the laws! They allow you to edit code without the aforementioned released-last-week test runner having to check all your code after a big refactor. I mean, you can't call something with a "flatMap" method and a "return" method a monad! There are tons of nonsensical definitions that fit that which are going to become very unpleasant to use quickly.
- dmitriid 9y ago
  > They allow you to edit code without the aforementioned released-last-week test runner having to check all your code after a big refactor. Oh wow. How did I ever live with big refactorings before? > There are tons of nonsensical definitions that fit that which are going to become very unpleasant to use quickly. I recently learned that, apparently, I've been using "monads" and "monadic composition" for years now, never knowing what it is. Can't remember any unpleasantness that would "quickly arise". There are other things than blind following after a Platonic ideal.
  - mrkgnao 9y ago
    The unpleasantness arises when writing Monad instances that don't follow the laws. Setting your disingenuity aside, try using xs >>= f = concat (reverse (map f xs)) or Array.prototype.chain = function (f) { return reverse(this.reduce((acc, it) => acc.concat(f(it)), [])) } (I don't know how JS works, but you get it) instead of xs >>= f = concat (map f xs) and enjoy refactoring your code, blissfully and consciously ignorant of the laws that make a monad a monad. The laws aren't just supposed to enrich the "life of the mind".
    - dmitriid 9y ago
      So, what problems will I experience while refactoring this code (if I ever wrote it)?
      - mrkgnao 9y ago
        It won't satisfy the properties you've come to expect from the implementations you know for lists, optionals (Maybe), and so on. Suppose you're going over some code, where you have something of the form xs >>= someFunction (where xs is a list) and you change someFunction to "return": xs >>= return Then you'd expect, from experience, that you can rewrite this to just xs (which you can check works with all the monads you know about) but that doesn't hold for this wonky definition of the Monad instance for lists. Indeed, note that return for lists has the definition return x = [x] so, with our bad >>=, [1, 2, 3] >>= return = concat (reverse (map (\x -> [x]) [1, 2, 3])) = concat (reverse ([[1], [2], [3]])) = concat [[3], [2], [1]] = [3, 2, 1] which is not the same as [1, 2, 3]. https://wiki.haskell.org/Monad_laws https://wiki.haskell.org/Monad_laws