• navigatron@beehaw.org
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Of course!

      In other words though, for those just starting their monad journey:

      An endofunctor is a box. If you have a box of soup, and a function to turn soup into nuts, you can probably turn the box of soup into a box of nuts. You don’t have to write a new function for this, if the box can take your existing function and “apply” it to its contents.

      Arrays are endofunctors, because they hold things, and you can use Array.map to turn an array of X into an array of Y.

      Monoids are things you can add together. Integer plus integer equals integer, so ints are monoids. String plus string (concatenation) equals a longer string, so strings are monoids. Grocery lists are monoids.

      Arrays are monoids!

      Arrays are both endofunctors and monoids, so for everyone except category theory purists, they are monads.

      Javascript promises hold things, and you can transform their contents with .then - so they are endofunctors. You can “add them together” with Promise.all (returning a new promise), so they are monoids. They are both monoids and endofunctors, so they are monads.

      I’ve just upset all the category theorists, but in the context of programming, that’s all it is. It’s surprisingly simple once you get it, it’s just complicated names for simple features.

      • GTG3000@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        “Complicated names for simple features” seems to describe Haskell crowd pretty well.

        Thank you for a straightforward explanation!

  • haruki@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    1 year ago

    Functional programming is so much fun. Sadly people usually give it complicated concepts to a point that it scares beginners away.

    I understand that by giving something a name, we have control and can communicate effectively with others about it (like design patterns). But still…

    • expr@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      It’s a pretty natural consequence of other languages simply not having a concept or word for the thing that we’re trying to abstract over, so better names simply don’t exist. I’ve yet to see anyone come up with a better name than “monad” for the concept. Same for monoids. We may as well use the names that come from math and are already used extensively rather than trying to invent some new name that would invariably be misleading anyway.

      Every single programming language is chock full of jargon that is basically meaningless to anyone unfamiliar with it. It’s really no different. The only difference is that monads are fundamentally an unfamiliar concept to many imperative programmers, particularly because programming in that style pretty much upends a basic assumption imperative programmers tend to have (namely, that the semantics of sequencing operations is a global, immutable property of programs).

  • GTG3000@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Man. I recall watching the Computerphile video on monads and the first thing the presenter did was choose Haskell for example language.

    Worst video of all of them, just some haskell masturbation. “Oooo, we can do infinite liiiists”. Bitch that’s called a generator.

  • zygo_histo_morpheus@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    A monad isn’t “a thing”, it’s a common interface shared by several different types that have a common mathematical structure that happens to be useful for structuring programs around. I think that’s why it’s so confusing to people, other programming languages tend to not have as abstract abstractions front and center.