5 ms·

For those looking for monadic Promises, I’d suggest taking a look at Fluture (https://github.com/fluture-js/Fluture https://github.com/fluture-js/Fluture). It’s

For those looking for monadic Promises, I’d suggest taking a look at Fluture (https://github.com/fluture-js/Fluture https://github.com/fluture-js/Fluture). It’s a wonderful library and with do-notation, ability to work with callbacks, nodebacks, and Promises, I haven’t looked back. It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def.

dahart 9y ago
> It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def. I think I understood a couple words in that sentence, like "it" and "has". :P Looking up fantasy-land, I found https://github.com/fantasyland/fantasy-land https://github.com/fantasyland/fantasy-land. I would like to better understand these monads everyone is talking about. But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putting. At a glance it just feels super complex, academic and completely divorced from practical coding. I get vibes of enterprise java class hierarchies looking at this stuff. I hope I'm wrong, and I really am interested to learn more about it, but I can see from the OP's linked thread that I'm not alone feeling this way. It's not at all clear why I should be thinking about my JavaScript algebraically at all times, or what the practical advantages are. After decades of coding, I'm just getting more alergic to complexity, and this feels like complexity. What are some good online resources that might help me change my mind and see the light?
- gcommer 9y ago
  This is one of the better javascript FP books that ramps into fairly advanced concepts: https://mostly-adequate.gitbooks.io/mostly-adequate-guide/ https://mostly-adequate.gitbooks.io/mostly-adequate-guide/ A simpler, gentler introduction is available from https://www.manning.com/books/functional-programming-in-javascript https://www.manning.com/books/functional-programming-in-java... > At a glance it just feels super complex, academic Agreed, because unfortunately, it is. (I might substitute "complex" with "hard" -- the ideas are actually very simple; understanding the big picture of how they fit together is hard) > It's not at all clear why I should be thinking about my JavaScript algebraically at all times, or what the practical advantages are. The main goal is to be able to write more and more code as pure functions -- this is hopefully an accepted best practice: functions with minimal inputs and no tangle of global state/context are far easier to reason about, test, and with proper data design, reuse. But you quickly run into an issue: how can I write pure, stateless functions when dealing with inherently stateful surroundings (IO, DOM, database, etc.). That's what all this category theory jargon is about.
- heycato 9y ago
  http://www.tomharding.me/ http://www.tomharding.me/ <-- excellent
- Nadya 9y ago
  "Once you understand monads, you immediately become incapable of explaining them to anyone else” Lady Monadgreen’s curse ~ Gilad Bracha" If you'd like to go down a rabbit hole of category theory look up the phrase "A monad is just a monoid in the category of endofunctors, what's the problem?" - a fun quote that a lot of monad explanatory tutorials will quip. Not that it will help - because anyone writing a monad explanation already suffers from the first quote: they're incapable of explaining them. I had read 30 or 35 different monads-for-Javascript tutorials/guides/explanations before I finally thought I grokked it. None of them have helped and I'm still not sure my understanding of them is correct.
  - icc97 9y ago
    Here's a half baked explanation, as in just the flatmap part. map is understood in javascript. So you 'just' need to make the leap to flatmap. Which is mapping something and flattening the result. So still you need to learn is what flatten is. But that's not too hard to learn. Try the funfunfunction video [0] [0]: https://m.youtube.com/watch?v=9QveBbn7t_c https://m.youtube.com/watch?v=9QveBbn7t_c
  - ngcazz 9y ago
    Because the point is mostly lost on the unrelated analogies most tutorial writers use. A monad is a mathematical construct. Trying to explain them in terms of what makes sense to you, because your analogy results from your understanding, isn't likely to be more helpful than outright accepting what they represent, mathematically speaking, then putting that to use in your code.
    - rmrfrmrf 9y ago
      A monad is most simply described as the quantum superposition of the state of being (or not being) a burrito.
  - zenhack 9y ago
    rmrfrmrf made an allusion to this below (which I also linked to in another nearby comment): https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti... The short version is: don't stare at explanations trying to grok it. Start hacking and keep an eye out for patterns.
- shados 9y ago
  The thing is the general problem with software development right now: What we know is "intuitive and simple". What we don't know is "off-putting and academic". Terminology is incredibly important in computer science. If you make something that's kind of like a promise, but not "quite" a promise, and call it a promise, a lot of problems wil arise when people use your code or try to debug it. Monads are pretty simple (they're a heck of a lot simpler than promises). The terminology manners because they're all about interop. If you make something like a monad, but it's not quite a monad, you essentially lose all the benefits (that's the problem with promises). Fantasy-land is a specification. It's meant for implementers, not for users. The important part is that people who build libraries that should work with other libraries also conforming to the spec, work well with each other. Take a look at some of the very simple constructs you might be used to, and how they are specified on the TC39's github. I'm quite familiar with the spec and I have trouble reading it, but I'm not the target audience. For the users, there are simpler resources. As for the terminology, inheritance, polymorphism, overloading are all words that a lot of people are familiar with. I'd say the terminology is way worse, and the concepts are often a lot more complex, but people are used to them because it's what they're taught. Java put in monad-like constructs in their Optionals, and it's a lot friendlier...except when trying to compare 2 libraries doing the same thing using 2 different 'friendly' terminology, it's hell. It's not about being academic or elitist, it's about being precise. Something I can google for without having to sort through 16 pages of unrelated crap. Google for monads, you'll get a lot of relevent material. Google for "optionals", and now you have to precise which language you're talking about, and in some cases potentially which library. If you want a friendlier intro, look up "Functional programming in javascript" by luis atencio. It's fantastic. I also always liked this tutorial: https://medium.com/@tzehsiang/javascript-functor-applicative-monads-in-pictures-b567c6415221 https://medium.com/@tzehsiang/javascript-functor-applicative... At the end of the day, you don't need to know what dynamic method dispatch is to use it. Only the implementers need to :) This is the same thing. Finally, yeah, some stuff look like "enterprise java". And there's a reason "enterprise java" existed: not all problems are easy. Some companies have hard problems to solve. Maybe it wasn't the best way to solve those problems, but a vanilla Rails REST api probably is worse. That doesn't mean everyone needs those solutions, but its nice that they exist. In this case, most people wouldn't have felt much difference if promises had been monads. But for the people who need monads, they're worse off by the current state of things.
- agentultra 9y ago
  I tried my best to write a series of posts [0] demonstrating functional programming concepts using practical examples. I've found that Javascript is actually a decent language for learning about currying and monads, etc, because it affords you the ability to pick up a little bit at a time. You can learn one little trick and use it to improve your existing code before picking up another. The nice thing about Monads is that once you learn the interface then encountering another is no big deal: you already know the API and how to use it. And it turns out this pattern is quite common. [0] https://agentultra.com/blog/mostly-practical-functional-programming-javascript-part-3/ https://agentultra.com/blog/mostly-practical-functional-prog...
  - mercer 9y ago
    While I agree, I've also found that it can be a danger. I thought I was all about the functional programming until I used languages that 'required' it. It was only then that I realized I'd been using non-functional escape hatches all over the place.
- zenhack 9y ago
  First, going straight to "How do I understand Monads?" is not a good idea. I remeber when this article showed up on the web, and I remember wishing it had been written before I started learning Haskell: https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti... If you want to understand monads, start hacking and watch for patterns. > But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putting. At a glance it just feels super complex, academic and completely divorced from practical coding. I get vibes of enterprise java class hierarchies looking at this stuff. Yeah, and here's my take on why it looks like that: First, the terminology is all borrowed from mathematics, hence the academic tone. People can debate on the merits of this; I think it makes more sense when you're making tools for folks who are already familiar with the usual notation, but e.g. if you're not dealing with people who are already accustomed to the way physisicts talk about things, "p" is probably not the best variable name for momentum, traditional as it may be. The authors of that document seem to have gone even farther in that direction than the Haskell folks -- Setoid? really? It's just fing equals! even Haskell calls it Eq. At least they kept Ord. Also, the design looks to be basically transliterated from Haskell. There's been no attempt to adapt it to either javascript's strengths or its weaknesses. For example: Conceptually a monoid is a special case of a category, but it's fiddly to abstract out the commonalities in Haskell because of the way the type system works. In javascript you could basically collapse the two, with id == empty and concat == compose. You might still want a blurb in there somewhere about the differences; not every category is a valid monoid, but there's no reason to have a whole separate hierarchy with different method names. * The whole TypeRep thing they talk about is a complication that is unnecessary in Haskell; having methods that aren't attached to an extant value is just a non-issue, because the compiler can figure out which one you mean based on the types. The libraries were designed around Haskell, and they lose something in translation. One of the things that kept in that thread was why not build some experience using these patterns before writing a spec? I tend to agree. The other thing is that it is a big pile of abstractions. Even when working in Haskell, though I am more or less familiar with all of the type classes on that chart, I've only really had call to use 9 of them. Including Eq(Setoid) and Ord. The abstractions can definitely get to be a bit much. There is some real use for this stuff; here's one I find kindof shiny: https://apfelmus.nfshost.com/articles/monoid-fingertree.html https://apfelmus.nfshost.com/articles/monoid-fingertree.html ...but I would say these abstractions are as applicable to day to day programming as the rest of computer science -- no more and no less. I'm with you on the complexity allergy thing. Lately I've been doing some stuff in elm[1], and the simplicity has been a wonderful breath of fresh air coming from Haskell. I might recommend it if you're curious about functional programming. Some of the same ideas are sprinkled throughout the libraries; every time you see a function called "andThen," there's a monad lurking there, but because elm doesn't have type classes, you won't find anything called Monad. The flip side is you end up writing more boilerplate than you would in a language that can abstract these things away. [1]: http://elm-lang.org/ http://elm-lang.org/
Shoothe 9y ago
Async/await is the do-notation for Promises and generators can be re-purposed as do-notation for any other monad, see e.g. https://curiosity-driven.org/monads-in-javascript#do https://curiosity-driven.org/monads-in-javascript#do

dahart 9y ago

> It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def. I think I understood a couple words in that sentence, like "it" and "has". :P Looking up fantasy-land, I found https://github.com/fantasyland/fantasy-land https://github.com/fantasyland/fantasy-land. I would like to better understand these monads everyone is talking about. But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putting. At a glance it just feels super complex, academic and completely divorced from practical coding. I get vibes of enterprise java class hierarchies looking at this stuff. I hope I'm wrong, and I really am interested to learn more about it, but I can see from the OP's linked thread that I'm not alone feeling this way. It's not at all clear why I should be thinking about my JavaScript algebraically at all times, or what the practical advantages are. After decades of coding, I'm just getting more alergic to complexity, and this feels like complexity. What are some good online resources that might help me change my mind and see the light?

gcommer 9y ago
This is one of the better javascript FP books that ramps into fairly advanced concepts: https://mostly-adequate.gitbooks.io/mostly-adequate-guide/ https://mostly-adequate.gitbooks.io/mostly-adequate-guide/ A simpler, gentler introduction is available from https://www.manning.com/books/functional-programming-in-javascript https://www.manning.com/books/functional-programming-in-java... > At a glance it just feels super complex, academic Agreed, because unfortunately, it is. (I might substitute "complex" with "hard" -- the ideas are actually very simple; understanding the big picture of how they fit together is hard) > It's not at all clear why I should be thinking about my JavaScript algebraically at all times, or what the practical advantages are. The main goal is to be able to write more and more code as pure functions -- this is hopefully an accepted best practice: functions with minimal inputs and no tangle of global state/context are far easier to reason about, test, and with proper data design, reuse. But you quickly run into an issue: how can I write pure, stateless functions when dealing with inherently stateful surroundings (IO, DOM, database, etc.). That's what all this category theory jargon is about.
heycato 9y ago
http://www.tomharding.me/ http://www.tomharding.me/ <-- excellent
Nadya 9y ago
"Once you understand monads, you immediately become incapable of explaining them to anyone else” Lady Monadgreen’s curse ~ Gilad Bracha" If you'd like to go down a rabbit hole of category theory look up the phrase "A monad is just a monoid in the category of endofunctors, what's the problem?" - a fun quote that a lot of monad explanatory tutorials will quip. Not that it will help - because anyone writing a monad explanation already suffers from the first quote: they're incapable of explaining them. I had read 30 or 35 different monads-for-Javascript tutorials/guides/explanations before I finally thought I grokked it. None of them have helped and I'm still not sure my understanding of them is correct.
- icc97 9y ago
  Here's a half baked explanation, as in just the flatmap part. map is understood in javascript. So you 'just' need to make the leap to flatmap. Which is mapping something and flattening the result. So still you need to learn is what flatten is. But that's not too hard to learn. Try the funfunfunction video [0] [0]: https://m.youtube.com/watch?v=9QveBbn7t_c https://m.youtube.com/watch?v=9QveBbn7t_c
- ngcazz 9y ago
  Because the point is mostly lost on the unrelated analogies most tutorial writers use. A monad is a mathematical construct. Trying to explain them in terms of what makes sense to you, because your analogy results from your understanding, isn't likely to be more helpful than outright accepting what they represent, mathematically speaking, then putting that to use in your code.
  - rmrfrmrf 9y ago
    A monad is most simply described as the quantum superposition of the state of being (or not being) a burrito.
- zenhack 9y ago
  rmrfrmrf made an allusion to this below (which I also linked to in another nearby comment): https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti... The short version is: don't stare at explanations trying to grok it. Start hacking and keep an eye out for patterns.
shados 9y ago
The thing is the general problem with software development right now: What we know is "intuitive and simple". What we don't know is "off-putting and academic". Terminology is incredibly important in computer science. If you make something that's kind of like a promise, but not "quite" a promise, and call it a promise, a lot of problems wil arise when people use your code or try to debug it. Monads are pretty simple (they're a heck of a lot simpler than promises). The terminology manners because they're all about interop. If you make something like a monad, but it's not quite a monad, you essentially lose all the benefits (that's the problem with promises). Fantasy-land is a specification. It's meant for implementers, not for users. The important part is that people who build libraries that should work with other libraries also conforming to the spec, work well with each other. Take a look at some of the very simple constructs you might be used to, and how they are specified on the TC39's github. I'm quite familiar with the spec and I have trouble reading it, but I'm not the target audience. For the users, there are simpler resources. As for the terminology, inheritance, polymorphism, overloading are all words that a lot of people are familiar with. I'd say the terminology is way worse, and the concepts are often a lot more complex, but people are used to them because it's what they're taught. Java put in monad-like constructs in their Optionals, and it's a lot friendlier...except when trying to compare 2 libraries doing the same thing using 2 different 'friendly' terminology, it's hell. It's not about being academic or elitist, it's about being precise. Something I can google for without having to sort through 16 pages of unrelated crap. Google for monads, you'll get a lot of relevent material. Google for "optionals", and now you have to precise which language you're talking about, and in some cases potentially which library. If you want a friendlier intro, look up "Functional programming in javascript" by luis atencio. It's fantastic. I also always liked this tutorial: https://medium.com/@tzehsiang/javascript-functor-applicative-monads-in-pictures-b567c6415221 https://medium.com/@tzehsiang/javascript-functor-applicative... At the end of the day, you don't need to know what dynamic method dispatch is to use it. Only the implementers need to :) This is the same thing. Finally, yeah, some stuff look like "enterprise java". And there's a reason "enterprise java" existed: not all problems are easy. Some companies have hard problems to solve. Maybe it wasn't the best way to solve those problems, but a vanilla Rails REST api probably is worse. That doesn't mean everyone needs those solutions, but its nice that they exist. In this case, most people wouldn't have felt much difference if promises had been monads. But for the people who need monads, they're worse off by the current state of things.
agentultra 9y ago
I tried my best to write a series of posts [0] demonstrating functional programming concepts using practical examples. I've found that Javascript is actually a decent language for learning about currying and monads, etc, because it affords you the ability to pick up a little bit at a time. You can learn one little trick and use it to improve your existing code before picking up another. The nice thing about Monads is that once you learn the interface then encountering another is no big deal: you already know the API and how to use it. And it turns out this pattern is quite common. [0] https://agentultra.com/blog/mostly-practical-functional-programming-javascript-part-3/ https://agentultra.com/blog/mostly-practical-functional-prog...
- mercer 9y ago
  While I agree, I've also found that it can be a danger. I thought I was all about the functional programming until I used languages that 'required' it. It was only then that I realized I'd been using non-functional escape hatches all over the place.
zenhack 9y ago
First, going straight to "How do I understand Monads?" is not a good idea. I remeber when this article showed up on the web, and I remember wishing it had been written before I started learning Haskell: https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti... If you want to understand monads, start hacking and watch for patterns. > But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putting. At a glance it just feels super complex, academic and completely divorced from practical coding. I get vibes of enterprise java class hierarchies looking at this stuff. Yeah, and here's my take on why it looks like that: First, the terminology is all borrowed from mathematics, hence the academic tone. People can debate on the merits of this; I think it makes more sense when you're making tools for folks who are already familiar with the usual notation, but e.g. if you're not dealing with people who are already accustomed to the way physisicts talk about things, "p" is probably not the best variable name for momentum, traditional as it may be. The authors of that document seem to have gone even farther in that direction than the Haskell folks -- Setoid? really? It's just fing equals! even Haskell calls it Eq. At least they kept Ord. Also, the design looks to be basically transliterated from Haskell. There's been no attempt to adapt it to either javascript's strengths or its weaknesses. For example: Conceptually a monoid is a special case of a category, but it's fiddly to abstract out the commonalities in Haskell because of the way the type system works. In javascript you could basically collapse the two, with id == empty and concat == compose. You might still want a blurb in there somewhere about the differences; not every category is a valid monoid, but there's no reason to have a whole separate hierarchy with different method names. * The whole TypeRep thing they talk about is a complication that is unnecessary in Haskell; having methods that aren't attached to an extant value is just a non-issue, because the compiler can figure out which one you mean based on the types. The libraries were designed around Haskell, and they lose something in translation. One of the things that kept in that thread was why not build some experience using these patterns before writing a spec? I tend to agree. The other thing is that it is a big pile of abstractions. Even when working in Haskell, though I am more or less familiar with all of the type classes on that chart, I've only really had call to use 9 of them. Including Eq(Setoid) and Ord. The abstractions can definitely get to be a bit much. There is some real use for this stuff; here's one I find kindof shiny: https://apfelmus.nfshost.com/articles/monoid-fingertree.html https://apfelmus.nfshost.com/articles/monoid-fingertree.html ...but I would say these abstractions are as applicable to day to day programming as the rest of computer science -- no more and no less. I'm with you on the complexity allergy thing. Lately I've been doing some stuff in elm[1], and the simplicity has been a wonderful breath of fresh air coming from Haskell. I might recommend it if you're curious about functional programming. Some of the same ideas are sprinkled throughout the libraries; every time you see a function called "andThen," there's a monad lurking there, but because elm doesn't have type classes, you won't find anything called Monad. The flip side is you end up writing more boilerplate than you would in a language that can abstract these things away. [1]: http://elm-lang.org/ http://elm-lang.org/

Shoothe 9y ago

Async/await is the do-notation for Promises and generators can be re-purposed as do-notation for any other monad, see e.g. https://curiosity-driven.org/monads-in-javascript#do https://curiosity-driven.org/monads-in-javascript#do