3 ms·

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

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?
      - AnimalMuppet 7y ago
        Does it explode your thesis? No. It can still be a good language for those who want purity and immutability that badly. Also, it can be a bad language for those who don't. And there's nothing wrong with wanting purity and immutability that badly. And there's nothing wrong with not. I suspect that FP fits the way some people think, and imperative fits how some other people think. And I don't think there's anything wrong with that. I'm a fan of picking the tool that is best suited to the job, and the person who is going to be using the tool is one of the biggest components of "suited". I might even say, of all the languages that suit you, pick the one that best suits the task.
    - dllthomas 7y ago
      Could you elaborate on what you find puzzling about Reader and Writer (and maybe State)? I've always thought of those as "simple": Their use is (seems?) straightforward - I have a context that can hand me a value, take values from me, or thread a state. Also, they're "just" thin wrappers around common types. `Reader r` is `r -> a`; `Writer w` is `(a, w)`; `State s` is `s -> (a, s)`. I'm interested whether you can unpack a bit where the difficulty seems to lie. Backgrounds differ and what's simple for one may be complex for another, without any judgement around overall capability.
- dllthomas 7y ago
  In my experience working full-time with a medium size team on production software, those things were not confusing in practice in that setting.

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?
    - AnimalMuppet 7y ago
      Does it explode your thesis? No. It can still be a good language for those who want purity and immutability that badly. Also, it can be a bad language for those who don't. And there's nothing wrong with wanting purity and immutability that badly. And there's nothing wrong with not. I suspect that FP fits the way some people think, and imperative fits how some other people think. And I don't think there's anything wrong with that. I'm a fan of picking the tool that is best suited to the job, and the person who is going to be using the tool is one of the biggest components of "suited". I might even say, of all the languages that suit you, pick the one that best suits the task.
  - dllthomas 7y ago
    Could you elaborate on what you find puzzling about Reader and Writer (and maybe State)? I've always thought of those as "simple": Their use is (seems?) straightforward - I have a context that can hand me a value, take values from me, or thread a state. Also, they're "just" thin wrappers around common types. `Reader r` is `r -> a`; `Writer w` is `(a, w)`; `State s` is `s -> (a, s)`. I'm interested whether you can unpack a bit where the difficulty seems to lie. Backgrounds differ and what's simple for one may be complex for another, without any judgement around overall capability.
dllthomas 7y ago
In my experience working full-time with a medium size team on production software, those things were not confusing in practice in that setting.