Live data from Hacker News

Effectful Haskell: IO, Monads, Functors

slpopejoy.github.io

41–50 of 68 posts

Re: Effectful Haskell: IO, Monads, Functors

#41
post #2

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.

How is the list monad a "computation builder"? Sounds to me like "programmable semicolons" and other nonsense: Monad is a typeclass that means very different things depending on what type you're using. It's the shape that has meaning: this level of abstraction is just going to be hard to grasp correctly no matter what you call it. Likewise with "Mappable": in most other languages, `map` is only an operation on lists…

As a novice programmer used to node.js, C, etc., how the hell is one supposed to get started with Haskell? I've tried multiple tutorials, read many articles like this, and still can't follow along.

It makes me wonder who ends up using this language for anything serious in even the slightest time crunch...

Re: Effectful Haskell: IO, Monads, Functors

#42

Earlier quoted context omitted.

How is the list monad a "computation builder"? Sounds to me like "programmable semicolons" and other nonsense: Monad is a typeclass that means very different things depending on what type you're using. It's the shape that has meaning: this level of abstraction is just going to be hard to grasp correctly no matter what you call it. Likewise with "Mappable": in most other languages, `map` is only an operation on lists…

As a novice programmer used to node.js, C, etc., how the hell is one supposed to get started with Haskell? I've tried multiple tutorials, read many articles like this, and still can't follow along. It makes me wonder who ends up using this language for anything serious in even the slightest time crunch...

Try these: learnyouahaskell.com haskellbook.com

Re: Effectful Haskell: IO, Monads, Functors

#43

Earlier quoted context omitted.

How is the list monad a "computation builder"? Sounds to me like "programmable semicolons" and other nonsense: Monad is a typeclass that means very different things depending on what type you're using. It's the shape that has meaning: this level of abstraction is just going to be hard to grasp correctly no matter what you call it. Likewise with "Mappable": in most other languages, `map` is only an operation on lists…

As a novice programmer used to node.js, C, etc., how the hell is one supposed to get started with Haskell? I've tried multiple tutorials, read many articles like this, and still can't follow along. It makes me wonder who ends up using this language for anything serious in even the slightest time crunch...

I recommend this, https://github.com/bitemyapp/learnhaskell

Re: Effectful Haskell: IO, Monads, Functors

#44
post #37
post #36

Earlier quoted context omitted.

> It's relatively common to refer to the underlying set as a monoid (or whatever structure you're talking about) if it's clear from the context what the operations are, though. Relatively common even outside Haskell?

> Relatively common even outside Haskell? It's common throughout mathematics. So common, in fact, that there's even a wikipedia article on the phenomenon[0]. “Common examples occur when speaking of compound mathematical objects. […] Similarly, one often refers to a group (G, \star) as simply G when the group operation is clear from context.” [0] https://en.wikipedia.org/wiki/Abuse_of_notation

Fair enough. But I don't think its surprising that it may lead to confusion when beginners study the subject.

Re: Effectful Haskell: IO, Monads, Functors

#45

Earlier quoted context omitted.

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.

It's worth observing that "background in math" here probably implies postgraduate study in a relevant field, which very few people will actually have done. The average new math graduate with a bachelor's degree might have heard of category theory but probably hasn't studied it during an undergraduate course. More generally, I think one problem the Haskell world has with attracting more developers is that it's dominat…

While it takes exposure to Category Theory to have knowledge of Monads in particular, a course in undergraduate level Abstract Algebra gives a good enough foothold to make the mathematical definitions of "monad" tractable.

Re: Effectful Haskell: IO, Monads, Functors

#46
post #26
post #10

Earlier quoted context omitted.

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…

A concise and good explanation thanks.

[deleted]

Re: Effectful Haskell: IO, Monads, Functors

#47
post #26
post #10

Earlier quoted context omitted.

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…

A concise and good explanation thanks.

Note that the word "monad" itself refers just to the "shape" of the object (and some rules about that shape), not the functionality.

For example, an array can be a monad if we define a bind method as map + flatten

  Array.prototype.flatMap = function(f) {
    return _.flatten(this.map(f))
  }
which works like so:

  allArticles = authors.flatMap(author => author.articles);
return would be

  Array.of = function(val) { return [val]; }
The shape (type) is the same:

the promise's bind (then) method takes a function that takes a value and returns a promise, and returns another promise

the array's bind (flatMap) method takes a function that takes a value and returns an array, and returns another array

the promise's return (Promise.resolve) method takes a value and wraps it in a promise

the array's return (Array.of) method takes a value and wraps it in an array.

You can get the array method types (shapes) from the promise ones by replacing promise with array (if you decide to give the methods the same name).

The implemented functionality, however, is vastly different.

Re: Effectful Haskell: IO, Monads, Functors

#48
post #2

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.

> Numerous tutorials and blog posts would never have been written if only functor was named mappable and monad was named computation builder.

If that were so, monad and functor tutorials would be as follows:

Functor tutorial: imagine it's called "mappable". End of tutorial.

Monad tutoral: imagine it's called "computation builder". End of tutorial

Re: Effectful Haskell: IO, Monads, Functors

#49

Earlier quoted context omitted.

How is the list monad a "computation builder"? Sounds to me like "programmable semicolons" and other nonsense: Monad is a typeclass that means very different things depending on what type you're using. It's the shape that has meaning: this level of abstraction is just going to be hard to grasp correctly no matter what you call it. Likewise with "Mappable": in most other languages, `map` is only an operation on lists…

As a novice programmer used to node.js, C, etc., how the hell is one supposed to get started with Haskell? I've tried multiple tutorials, read many articles like this, and still can't follow along. It makes me wonder who ends up using this language for anything serious in even the slightest time crunch...

The big not-so-secret secret is that you don't have to understand much of Monad theory to enjoy Haskell. If you want to use Haskell as a nice functional language with a great typesystem.

As spopejoy says, Monad is a typeclass, that means every Monad is a type on itself. So you you can get by just learning every monad for its use without ever needing to know the theory that binds them.

The Maybe Monad is just an option type, the list monad is just a list and the IO monad is just a sequence of operations that gets returned to the runtime from the main function. Who cares that they all share a typeclass?

Re: Effectful Haskell: IO, Monads, Functors

#50

Earlier quoted context omitted.

How is the list monad a "computation builder"? Sounds to me like "programmable semicolons" and other nonsense: Monad is a typeclass that means very different things depending on what type you're using. It's the shape that has meaning: this level of abstraction is just going to be hard to grasp correctly no matter what you call it. Likewise with "Mappable": in most other languages, `map` is only an operation on lists…

As a novice programmer used to node.js, C, etc., how the hell is one supposed to get started with Haskell? I've tried multiple tutorials, read many articles like this, and still can't follow along. It makes me wonder who ends up using this language for anything serious in even the slightest time crunch...

I've heard good things about the opening sections of the WikiBook - and if it is hard to understand, ask questions and then improve it! :)

https://en.wikibooks.org/wiki/Haskell

Post reply on HN