5 ms·

Haskell people claim that combinators and monads are clear, but in practice the code seems to be write-only. Each combinator might be simple, but that doesn’t m

Haskell people claim that combinators and monads are clear, but in practice the code seems to be write-only. Each combinator might be simple, but that doesn’t mean that the result can be understood easily. And monads have the same problem, except they aren’t simple.

jsjolen 7y ago
Javascript programmers seem to have no problem using a monad every day (promises), and they are huge fans of do-notation in the from of async/await. Imperative programmers do not seem to have an issue with the idea of assignment, why are monads problematic? By "combinator" do you mean combinator as in the combinator pattern? I have no idea what value your comment brings us except a way for people who already agree with you to give you upvotes, and what's the point in that?
- jowiar 7y ago
  The big issue with Haskell isn’t the concepts — it’s the syntax. ASCII art as code is an abomination. Being unable to read code upon first glance it makes it inaccessible.
- jes5199 7y ago
  getting people who already agree with me to give me upvotes is the whole point of this website
- AnimalMuppet 7y ago
  > Imperative programmers do not seem to have an issue with the idea of assignment, why are monads problematic? This drive-by-question style makes it hard for me to know what your real point is. Are you saying that an assignment does the same thing as a monad? OK. That it is a monad? I doubt it; assignment doesn't have the right operators (you might argue that it does, but you'd have to really stretch it.) That it's just as simple and easy to understand as a monad? I call BS. > I have no idea what value your comment brings us except a way for people who already agree with you to give you upvotes, and what's the point in that? That kind of rhetoric is against the site guidelines.
- dragonwriter 7y ago
  > Javascript programmers seem to have no problem using a monad every day (promises) Using (something similar to) a monad (Javascript promises do not form a monad) successfully is different than using the monad abstraction successfully. > and they are huge fans of do-notation in the from of async/await. Async / await is not monadic do-notation. Arguably, it has a somewhat similar relationship to the underlying promise abstraction that do-notation had to the monad abstraction, but they aren't the same thing. > Imperative programmers do not seem to have an issue with the idea of assignment, why are monads problematic Why are the two halves of this sentence connected to each other since they have no relationship other than the proximity they've been (bizarrely) placed in.
  - jsjolen 7y ago
    Yeah, you're right that in some manners JS's promises do extend the semantics of a monad (notably in its impl. of return) but it is a monad though: function bindPromise(p, f) { return p.then(f); } function returnPromise(a) { return new Promise.resolve(a); } Proof of the laws left as an exercise to the reader :). But yes, you are correct that promises do quite a bit more than only being a monad, for example because of how they treat errors. EDIT: I concede, I am wrong! https://buzzdecafe.github.io/2018/04/10/no-promises-are-not-monads https://buzzdecafe.github.io/2018/04/10/no-promises-are-not-...
- didibus 7y ago
  Generally, I think people don't like Promises and async/await, since it is very goto like, but there's not a whole lot better currently. I also think there's nothing precluding some Monads to be good ideas and others to be bad ideas. Similarly, the delivery could have a big impact. So it might be the theory of it is good, but a better delivery in terms of programming UX needs to be used. So maybe the dot notation somehow delivers better then the do notation. Having said all that, I like Haskell, better than JS.
- merb 7y ago
  Promises are not monads. neither are scala's future.
  - zzo38computer 7y ago
    I don't use Promises much, but Generators is like monads (but not monads on a category of pure functions, like it is in Haskell; also, these "monads" in JavaScript are not pure monads); actually, two kind of monads: return x; return x -> return yield*x return yield x; yield x -> yield*x (at least, I think it is; I may have made a mistake)
whateveracct 7y ago
It's not write-only in practice in my years of professional experience :)
- dllthomas 7y ago
  Likewise. That said, I think there are some legitimate reasons for the impression. For one, Haskell (not uniquely) lacks the distinction between statement and expression found in many languages. This means that you have a freer hand about "where you cut" when breaking up your problem. In a way this is good - the optimal choice may be better when you have more options. But it also means a lack of consistency and more to learn about how to do it well. Haskell's syntax is unusual. Everything is a harder to follow when you still need to work to parse things. There is a frustrating space between knowing the syntax well enough to want to learn other things and being sufficiently fluent that the new concepts are the only hard thing. There are habits to reading Haskell code that differ from those involved in reading other languages - a big one being knowing how the types flow through an expression and how to spot where they're pinned down in various contexts.
philzook 7y ago
I personally do not claim that Monadic code is clearer to read nor easy. But I think it is ultimately worth it in that the TYPES of monadic code are clearer and compiler enforced. By combinators I did not necessarily imply punctuation operators like (=--><><) which I also get can get confused by. I mean very small simple named functions duplicate, inparallel, fanout, first, second these sorts of things from which you can build your tower of power.
- jes5199 7y ago
  I like Haskell types, generally, but I think that both the monad types themselves and the syntactic sugar over them are both extremely confusing both in theory and in practice
  - philzook 7y ago
    It can get quite bad, yes. I find the simple cases pleasant at least. a -> Maybe b is the signature of a partial function. a -> State s b is a function that can mutate state, a -> [b] is a function that nondeterministically returns many results. I think these are clear. When you need to grab for multiples of them, it gets hairy. This is a problem the community acknowledges and is trying to make better.
    - jes5199 7y ago
      those three are clear - but the next most complicated ones (Reader and Writer) are head-scratchers, and any beyond that are just completely opaque. And that’s not even considering monad transformers!
      - philzook 7y ago
        Yeah. I think you have exposed my double think. I really WANT to like that stuff regardless of the facts, but I might not. Monads are not my favorite part of Haskell. They hurt. But purity and immutability is. I want these at almost any cost. And if monadic pain is the price, so be it. Does this explode my entire thesis that Haskell is a good pragmatic language?

jsjolen 7y ago

Javascript programmers seem to have no problem using a monad every day (promises), and they are huge fans of do-notation in the from of async/await. Imperative programmers do not seem to have an issue with the idea of assignment, why are monads problematic? By "combinator" do you mean combinator as in the combinator pattern? I have no idea what value your comment brings us except a way for people who already agree with you to give you upvotes, and what's the point in that?

jowiar 7y ago
The big issue with Haskell isn’t the concepts — it’s the syntax. ASCII art as code is an abomination. Being unable to read code upon first glance it makes it inaccessible.
jes5199 7y ago
getting people who already agree with me to give me upvotes is the whole point of this website
AnimalMuppet 7y ago
> Imperative programmers do not seem to have an issue with the idea of assignment, why are monads problematic? This drive-by-question style makes it hard for me to know what your real point is. Are you saying that an assignment does the same thing as a monad? OK. That it is a monad? I doubt it; assignment doesn't have the right operators (you might argue that it does, but you'd have to really stretch it.) That it's just as simple and easy to understand as a monad? I call BS. > I have no idea what value your comment brings us except a way for people who already agree with you to give you upvotes, and what's the point in that? That kind of rhetoric is against the site guidelines.
dragonwriter 7y ago
> Javascript programmers seem to have no problem using a monad every day (promises) Using (something similar to) a monad (Javascript promises do not form a monad) successfully is different than using the monad abstraction successfully. > and they are huge fans of do-notation in the from of async/await. Async / await is not monadic do-notation. Arguably, it has a somewhat similar relationship to the underlying promise abstraction that do-notation had to the monad abstraction, but they aren't the same thing. > Imperative programmers do not seem to have an issue with the idea of assignment, why are monads problematic Why are the two halves of this sentence connected to each other since they have no relationship other than the proximity they've been (bizarrely) placed in.
- jsjolen 7y ago
  Yeah, you're right that in some manners JS's promises do extend the semantics of a monad (notably in its impl. of return) but it is a monad though: function bindPromise(p, f) { return p.then(f); } function returnPromise(a) { return new Promise.resolve(a); } Proof of the laws left as an exercise to the reader :). But yes, you are correct that promises do quite a bit more than only being a monad, for example because of how they treat errors. EDIT: I concede, I am wrong! https://buzzdecafe.github.io/2018/04/10/no-promises-are-not-monads https://buzzdecafe.github.io/2018/04/10/no-promises-are-not-...
didibus 7y ago
Generally, I think people don't like Promises and async/await, since it is very goto like, but there's not a whole lot better currently. I also think there's nothing precluding some Monads to be good ideas and others to be bad ideas. Similarly, the delivery could have a big impact. So it might be the theory of it is good, but a better delivery in terms of programming UX needs to be used. So maybe the dot notation somehow delivers better then the do notation. Having said all that, I like Haskell, better than JS.
merb 7y ago
Promises are not monads. neither are scala's future.
- zzo38computer 7y ago
  I don't use Promises much, but Generators is like monads (but not monads on a category of pure functions, like it is in Haskell; also, these "monads" in JavaScript are not pure monads); actually, two kind of monads: return x; return x -> return yield*x return yield x; yield x -> yield*x (at least, I think it is; I may have made a mistake)

whateveracct 7y ago

It's not write-only in practice in my years of professional experience :)

dllthomas 7y ago
Likewise. That said, I think there are some legitimate reasons for the impression. For one, Haskell (not uniquely) lacks the distinction between statement and expression found in many languages. This means that you have a freer hand about "where you cut" when breaking up your problem. In a way this is good - the optimal choice may be better when you have more options. But it also means a lack of consistency and more to learn about how to do it well. Haskell's syntax is unusual. Everything is a harder to follow when you still need to work to parse things. There is a frustrating space between knowing the syntax well enough to want to learn other things and being sufficiently fluent that the new concepts are the only hard thing. There are habits to reading Haskell code that differ from those involved in reading other languages - a big one being knowing how the types flow through an expression and how to spot where they're pinned down in various contexts.

philzook 7y ago

I personally do not claim that Monadic code is clearer to read nor easy. But I think it is ultimately worth it in that the TYPES of monadic code are clearer and compiler enforced. By combinators I did not necessarily imply punctuation operators like (=--><><) which I also get can get confused by. I mean very small simple named functions duplicate, inparallel, fanout, first, second these sorts of things from which you can build your tower of power.

jes5199 7y ago
I like Haskell types, generally, but I think that both the monad types themselves and the syntactic sugar over them are both extremely confusing both in theory and in practice
- philzook 7y ago
  It can get quite bad, yes. I find the simple cases pleasant at least. a -> Maybe b is the signature of a partial function. a -> State s b is a function that can mutate state, a -> [b] is a function that nondeterministically returns many results. I think these are clear. When you need to grab for multiples of them, it gets hairy. This is a problem the community acknowledges and is trying to make better.
  - jes5199 7y ago
    those three are clear - but the next most complicated ones (Reader and Writer) are head-scratchers, and any beyond that are just completely opaque. And that’s not even considering monad transformers!
    - philzook 7y ago
      Yeah. I think you have exposed my double think. I really WANT to like that stuff regardless of the facts, but I might not. Monads are not my favorite part of Haskell. They hurt. But purity and immutability is. I want these at almost any cost. And if monadic pain is the price, so be it. Does this explode my entire thesis that Haskell is a good pragmatic language?