Effectful Haskell: IO, Monads, Functors
slpopejoy.github.io
Effectful Haskell: IO, Monads, Functors
1–10 of 68 posts
Re: Effectful Haskell: IO, Monads, Functors
#2Naming 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.
Re: Effectful Haskell: IO, Monads, Functors
#3Naming 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.
Yeah, the Haskell culture seems to have a problem with naming. It uses a lot of mathematical terms and a lot of alphabet soup identifiers. Part of the problem is just that naming highly abstract things is hard (what would be a meaningful name for the monadic return operation?) Another part is that the commercial programming world has developed a whole art of naming things so that a maintenance programmer can understand them easily, but the Haskell community doesn't want to use that art because it reminds them of Java or something.
Re: Effectful Haskell: IO, Monads, Functors
#4Naming 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.
Yeah, the Haskell culture seems to have a problem with naming. It uses a lot of mathematical terms and a lot of alphabet soup identifiers. Part of the problem is just that naming highly abstract things is hard (what would be a meaningful name for the monadic return operation?) Another part is that the commercial programming world has developed a whole art of naming things so that a maintenance programmer can understa…
I think your first part is intimately related to the second one. You can't use "maintenance programmer" names such as real-world analogues if your language is highly abstract; they carry too many incorrect assumptions to be precise.
Re: Effectful Haskell: IO, Monads, Functors
#5Naming 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.
Re: Effectful Haskell: IO, Monads, Functors
#6Naming 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 different from being vague.
[1]: https://yow.eventer.com/yow-2014-1222/stop-treading-water-le... (around the 20 minute mark).
Re: Effectful Haskell: IO, Monads, Functors
#7So 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 ?
Re: Effectful Haskell: IO, Monads, Functors
#8So 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.
Re: Effectful Haskell: IO, Monads, Functors
#9Here's the next article in the series:
Re: Effectful Haskell: IO, Monads, Functors
#10So 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 already executed action