21–30 of 68 posts
So is it possible to explain monads with Javascript ? or even LISP ? seems to me monads == haskell so if one doesn't understand haskell one can't understand monads , cause all monad tutorials are written in haskell. So I ask , what is the point of learning what a monad is if i'm writing some Java ?
https://www.google.fr/search?q=jvtoups+monads
I hope you know lisp just enough to adapt to the lisp-1 lisp-2 namespace.
Naming is one area where Haskell's academic background is more curse than blessing. Numerous tutorials and blog posts would never have been written if only functor was named mappable and monad was named computation builder. They're named by analogy to category theory, but their usage in computer science is not at all similar.
Sure, their instances (implementations) are values (dictionaries of functions which are implicitly passed around) but thats beside the point when learning.
Earlier quoted context omitted.
Their usage in Haskell/OCaml etc is precisely faithful to their category theoretic definitions as can be in a general purpose language. This debate about naming monads is pretty tiresome after so many years, if one called it "computation builder" it wouldn't change their structure or convey any notion of the laws any better than term monad. A monad at it's core is a set of algebraic relations.
Can you elaborate a bit on the last sentence? What exactly are the relations and what is the set?
If you want a mathematical exposition. "Category Theory" by Awodey page 265 is a concise description.
So is it possible to explain monads with Javascript ? or even LISP ? seems to me monads == haskell so if one doesn't understand haskell one can't understand monads , cause all monad tutorials are written in haskell. So I ask , what is the point of learning what a monad is if i'm writing some Java ?
Naming is one area where Haskell's academic background is more curse than blessing. Numerous tutorials and blog posts would never have been written if only functor was named mappable and monad was named computation builder. They're named by analogy to category theory, but their usage in computer science is not at all similar.
Their naming is similar enough to leverage existing research literature, and knowledge, though. Those with a background in math can map some of their existing knowledge. Those without a math background have a more precise vocabulary to understand the concepts and research further. Even if they are a bit foreign, I prefer the attempt to be precise.
More generally, I think one problem the Haskell world has with attracting more developers is that it's dominated by people with a very "pure maths" mindset. The people developing and advocating Haskell often enjoy exploring the abstraction possibilities and interactions for their own sake, just as a research pure mathematician studying some form of advanced algebra might. Of course, there's nothing wrong with that, and as a platform for programming language research it's probably an asset to have a lot of such people involved. However, most other people, even those of a technical persuasion, do not find such a purely theoretical approach interesting. They want motivation for any theory they are learning and they want practical applications to show why it's relevant.
So is it possible to explain monads with Javascript ? or even LISP ? seems to me monads == haskell so if one doesn't understand haskell one can't understand monads , cause all monad tutorials are written in haskell. So I ask , what is the point of learning what a monad is if i'm writing some Java ?
Yes. Infact, a JavaScript Promise is pretty much the same as the IO monad* - the `then` method is a lot like `bind`. Promise.resolve is a lot like `return` * almost the same to IO, because of recursive thenable assimilation, something that was added to promises but is totally short-sighted and unnecessary; and because promises are eager which means they don't represent the action to be executed, but the value of an a…
Naming is one area where Haskell's academic background is more curse than blessing. Numerous tutorials and blog posts would never have been written if only functor was named mappable and monad was named computation builder. They're named by analogy to category theory, but their usage in computer science is not at all similar.
My problem wasn't the word but the fact that the word is not adjective - originally I spent a lot of time thinking "where is the monad?". This of course is the wrong question to ask, but if the word was "monadic" instead, then I would've known that this is a property (like iterable, foldable, applicative etc), and realized I should think of typeclasses more in terms of interfaces rather than values. Sure, their insta…
It's harder than it has to be, but it's also more powerful than it has to be. Because against the right kind of problem, it'll be just barely powerful enough.
So is it possible to explain monads with Javascript ? or even LISP ? seems to me monads == haskell so if one doesn't understand haskell one can't understand monads , cause all monad tutorials are written in haskell. So I ask , what is the point of learning what a monad is if i'm writing some Java ?
For one example, Scala's `for` syntax is quite similar to Haskell's `do` notation, and lets you do some monadic things with `Option`, `Seq`, and other classes. And then you can go much further into that world with the scalaz library.
One of those things was Scala's `for` (and `flatMap`). It clicked for me once I noticed how similar it was to Haskell's `do` notation for Monads.
What's surprising to me is that it would seem Haskell has no right to be this helpful for understanding production code!
Naming is one area where Haskell's academic background is more curse than blessing. Numerous tutorials and blog posts would never have been written if only functor was named mappable and monad was named computation builder. They're named by analogy to category theory, but their usage in computer science is not at all similar.
The Haskell monad typeclass _is_ (modulo technical details) a category-theoretic monad on the category `Hask`. As Edward Kmett says in more detail in [1] - the point of calling a monad a monad is not to confuse the reader, but to unlock 70 years of documentation on the concept for the reader. How many programming concepts/tools/libraries do you use that have 70 years of documentation? Being abstract is profoundly dif…
This is probably more off-putting than you suspect
Earlier quoted context omitted.
My problem wasn't the word but the fact that the word is not adjective - originally I spent a lot of time thinking "where is the monad?". This of course is the wrong question to ask, but if the word was "monadic" instead, then I would've known that this is a property (like iterable, foldable, applicative etc), and realized I should think of typeclasses more in terms of interfaces rather than values. Sure, their insta…
That's something you have to learn to do. It's like asking "where is the stack?" when you're just calling functions. If you don't develop some skill for seeing how your code implements underlying abstractions, you will be missing out. You can program without knowing what a stack is. But if you want to solve a problem using a stack, it helps to know that your function call stack can be 'overloaded' to solve stack prob…
The set of natural numbers N is not a monoid; {N, +, 0} is a monoid. The set may, at best, be "monoidal" (i.e. there exists associative binary operator and a set member ZERO such that for all elements of the set, ZERO x == x ZERO == x).
So as a beginner, it doesn't even help to try and read the "70 years of literature" on the subject, because what you read there does not match (I'm reading about a set, an operation and an element of the set - and all I have here is the actual set. Where are the operation and the element? Oh they are defined and passed implicitly for the type. Oh so the type isn't the monoid, its at best MONOIDAL)