3 ms·

Demonstrate a pair of tutorials aimed at the same level of reader, one in JS, and one in Haskell, where you end up with a better understanding of the idea of a

Demonstrate a pair of tutorials aimed at the same level of reader, one in JS, and one in Haskell, where you end up with a better understanding of the idea of a monad reading the former (as opposed to the implementation of the Monad instance for a list).

dmitriid 9y ago
TIL there's some "idea of a monad". Basically this is (in my mind) what's wrong with Haskell: it's overly concerned with the Platonic ideal. Meanwhile that one page on jargon has shown me that I effortlessly implement any and all of those things daily (and understanding what I'm doing) without the need to understand "an idea". I just use the tool that solves the problem. If someone insists on calling this "monadic composition", or "lifting over typeclasses", or "zygohistomorphic prepromorphisms", so be it.
- mrkgnao 9y ago
  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
- KirinDave 9y ago
  > Basically this is (in my mind) what's wrong with Haskell: it's overly concerned with the Platonic ideal. I read this and I think what's got you rustled here is that Monad is such a generic concept. It's quite higher level and so you can do novel things like write functions that don't know how they're executing, just that they are. As an example: -- Config is a typeclass that enables getting a -- keyval from a config. The return type is MonadIO -- because config might need IO. loadTarget :: (MonadIO m, Config a) => a -> m a loadTarget config = do v <- grabKeyVal "host" config w <- grabKeyVal "port" config return (v,w) What does that code do? The answer (if it's written carefully) is that it depends on what the underlying monad is! And that's a good thing, in many cases. If the monad is Maybe + IO, then you have a conditional loader. But if the monad is an array and IO then you can specify many hosts and many ports and this code enumerates them all. If that's passed to a ping function like so: loadTarget config >>= pingHostPort -- alternatively doPings config = do hostPort <- loadTarget config pingHostPort hostPort Well then your code will do the right thing, but a different thing, based entirely on the types alone! And you can generalize this out to even more powerful types. For example, you could write a web app that server side could do local network ports for you (why? you're a maliclious hacker of course!). In that case it might make sense to use the Continuation monad. tl;dr and finally: You say this is stupid abstract stuff, but the folks delivering features to you in the Javascript world disagree. You have generators now, which are a much more real and fair explanation of how to model monads in Javascript than that silly code snippet you posted that doesn't capture the spirit of them at all. What's more, careful application of these concepts leads to libraries which are just better than anything you can have without appealing to generators. A great example of this Purescript-config. Here is an actual (redacted) same of some code I use at work in an AWS Lambda function to read the environment: https://gist.github.com/KirinDave/9af0fc90d005164743198692f380d4d9 https://gist.github.com/KirinDave/9af0fc90d005164743198692f3... So I have complete error reporting (full sets of missing keys) just by describing how to fetch the values from the environment. I can transparently switch to any other file type under the covers by changing from using "fromEnv". I only know that there is a key-value store in there. Doing this in OO is really, really hard to get right, because imperative OO code cannot easily parameterize the execution strategy hierarchically without appealing to generics and ad-hoc polymorphism. That's hard. The applicative style adopted here is very simple to re-interpret, because we can parameterize code on monads and applicatives (which explain the execution strategy of this code beyond its coarse structure) as we see fit. You can do that with generators but it's frustratingly hard. Doing it in a truly generic way? Even harder. For this approach, the results are free (and Free, but hey). I can give you other examples of how Purescript makes certain difficult aspects of javascript simply vanish, if you'd like.

dmitriid 9y ago

TIL there's some "idea of a monad". Basically this is (in my mind) what's wrong with Haskell: it's overly concerned with the Platonic ideal. Meanwhile that one page on jargon has shown me that I effortlessly implement any and all of those things daily (and understanding what I'm doing) without the need to understand "an idea". I just use the tool that solves the problem. If someone insists on calling this "monadic composition", or "lifting over typeclasses", or "zygohistomorphic prepromorphisms", so be it.

mrkgnao 9y ago
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
KirinDave 9y ago
> Basically this is (in my mind) what's wrong with Haskell: it's overly concerned with the Platonic ideal. I read this and I think what's got you rustled here is that Monad is such a generic concept. It's quite higher level and so you can do novel things like write functions that don't know how they're executing, just that they are. As an example: -- Config is a typeclass that enables getting a -- keyval from a config. The return type is MonadIO -- because config might need IO. loadTarget :: (MonadIO m, Config a) => a -> m a loadTarget config = do v <- grabKeyVal "host" config w <- grabKeyVal "port" config return (v,w) What does that code do? The answer (if it's written carefully) is that it depends on what the underlying monad is! And that's a good thing, in many cases. If the monad is Maybe + IO, then you have a conditional loader. But if the monad is an array and IO then you can specify many hosts and many ports and this code enumerates them all. If that's passed to a ping function like so: loadTarget config >>= pingHostPort -- alternatively doPings config = do hostPort <- loadTarget config pingHostPort hostPort Well then your code will do the right thing, but a different thing, based entirely on the types alone! And you can generalize this out to even more powerful types. For example, you could write a web app that server side could do local network ports for you (why? you're a maliclious hacker of course!). In that case it might make sense to use the Continuation monad. tl;dr and finally: You say this is stupid abstract stuff, but the folks delivering features to you in the Javascript world disagree. You have generators now, which are a much more real and fair explanation of how to model monads in Javascript than that silly code snippet you posted that doesn't capture the spirit of them at all. What's more, careful application of these concepts leads to libraries which are just better than anything you can have without appealing to generators. A great example of this Purescript-config. Here is an actual (redacted) same of some code I use at work in an AWS Lambda function to read the environment: https://gist.github.com/KirinDave/9af0fc90d005164743198692f380d4d9 https://gist.github.com/KirinDave/9af0fc90d005164743198692f3... So I have complete error reporting (full sets of missing keys) just by describing how to fetch the values from the environment. I can transparently switch to any other file type under the covers by changing from using "fromEnv". I only know that there is a key-value store in there. Doing this in OO is really, really hard to get right, because imperative OO code cannot easily parameterize the execution strategy hierarchically without appealing to generics and ad-hoc polymorphism. That's hard. The applicative style adopted here is very simple to re-interpret, because we can parameterize code on monads and applicatives (which explain the execution strategy of this code beyond its coarse structure) as we see fit. You can do that with generators but it's frustratingly hard. Doing it in a truly generic way? Even harder. For this approach, the results are free (and Free, but hey). I can give you other examples of how Purescript makes certain difficult aspects of javascript simply vanish, if you'd like.