4 ms·

> Basically every obscure overly complicated concept that Haskell throws at you (all the while pretending to be the only true FP language out there) can be expl

• dmitriid 9y ago
  But they can't, can they. Or we wouldn't have the bazillion monad tutorials. The funny thing, this is the trouble that plagues other Haskell-inspired work (such as Purescript)
  • tome 9y ago
    It's obvious that the concept of monad can either be explained in 5-10 lines in both JavaScript and Haskell, or neither. Which are you claiming?
    • dmitriid 9y ago
      It's not obvious. I'm claiming that: - the concept of monad can be explained in 5-10 lines in Javascript (demonstrable) - the concept of a monad requires multiple years and tens of tutorials in Haskell (also demonstrable)
      • mrkgnao 9y ago
        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.
      • KirinDave 9y ago
        I just want to reiterate: point 1 is totally false. That description you linked is incredibly incorrect, captures almost nothing of the spirit of what a monad is, and is somewhat disingenuous. Lots of people get excited about "monads" and then rush out to write tutorials to try and capture whatever mental model they're using. These mental models may arrive at correct results most of the time, but they're often not really transferrable to another human. Learn You A Haskell takes a different approach, in which you arrive at creating monads because you naturally derive them as a way to deal with the tedium of functional code w/out such mechanisms. "Monad tutorials" are becoming much less frequent now that such approaches are offered. Everyone just says, "Go read this chapter or two of this freely available book and you're good to go." You know, just like any major feature in javascript.