3 ms·

plesn, I don't disagree that the reasons are shallow, but it turns out that solving some problems in Haskell is just plain hard. It's precisely because the is

plesn, I don't disagree that the reasons are shallow, but it turns out that solving some problems in Haskell is just plain hard. It's precisely because the issues/reasons are basic that it's hard... Also, I'm confused by your comment about the IO monad & logging... How would you log outside of the IO monad? Would also be cool if you'd point me to your Haskell repo. I'd be curious to see how you solve these problems. - Alson

jrockway 17y ago
How would you log outside of the IO monad? By collecting status messages in addition to computation results. The Writer monad is one (convenient) way to do this.
- harshavr 17y ago
  Can you clarify? I thought that keeping separate streams of side effects is not possible when one stream influences the other. The logging process depends on what actions happen in the IO sequence though not the other way around. Are you talking about keeping the normal IO actions in one monad, logging actions in another & then composing the two into an outer IO monad?
  - tel 17y ago
    It depends on what you're logging. Pure code can keep its own log in Writer and then depose the whole thing to the IO logger later. Since there's no guarantee of the timing or synchronicity on non-IO code, this works well.
plesn 17y ago
"solving problems in Haskell is just plain hard" That's what I agree with: Haskell nearly requires programmers to read papers each time they want to solve a new problem [1]... For the logging, I mean of course you can't be ultimately outside the IO Monad, but I don't like putting many things directly into it, if so I would prefer using the writer monad, or an additional argument, or something... I'm sorry though i don't have any public repo, I'm more of a lazy tinkerer... Edit: [1] But I would like to add that there is also cultural bias of our comp-sci education, otherwise C++ can sometimes also be quite harsh...
- olliesaunders 17y ago
  Haskell nearly requires programmers to read papers each time they want to solve a new problem. Why is that?
  - plesn 17y ago
    Because it's conceptually different from what we learn, and semantically very rich. You have many 'aha!' moments, seeing that an abstraction corresponds to a really better way to solve a problem. And because it's research oriented: maybe a simpler language with 80% of Haskell benefits will emerge out of it once those concepts have matured in Haskell. And maybe mostly because people learning Haskell do it by curiosity, so they'd like to explore the best way to do it, not being under their boss/client 's pressure.
yummyfajitas 17y ago
The Writer monad is better suited to logging than IO. http://www.haskell.org/all_about_monads/html/writermonad.html http://www.haskell.org/all_about_monads/html/writermonad.htm...

jrockway 17y ago

How would you log outside of the IO monad? By collecting status messages in addition to computation results. The Writer monad is one (convenient) way to do this.

harshavr 17y ago
Can you clarify? I thought that keeping separate streams of side effects is not possible when one stream influences the other. The logging process depends on what actions happen in the IO sequence though not the other way around. Are you talking about keeping the normal IO actions in one monad, logging actions in another & then composing the two into an outer IO monad?
- tel 17y ago
  It depends on what you're logging. Pure code can keep its own log in Writer and then depose the whole thing to the IO logger later. Since there's no guarantee of the timing or synchronicity on non-IO code, this works well.

plesn 17y ago

"solving problems in Haskell is just plain hard" That's what I agree with: Haskell nearly requires programmers to read papers each time they want to solve a new problem [1]... For the logging, I mean of course you can't be ultimately outside the IO Monad, but I don't like putting many things directly into it, if so I would prefer using the writer monad, or an additional argument, or something... I'm sorry though i don't have any public repo, I'm more of a lazy tinkerer... Edit: [1] But I would like to add that there is also cultural bias of our comp-sci education, otherwise C++ can sometimes also be quite harsh...

olliesaunders 17y ago
Haskell nearly requires programmers to read papers each time they want to solve a new problem. Why is that?
- plesn 17y ago
  Because it's conceptually different from what we learn, and semantically very rich. You have many 'aha!' moments, seeing that an abstraction corresponds to a really better way to solve a problem. And because it's research oriented: maybe a simpler language with 80% of Haskell benefits will emerge out of it once those concepts have matured in Haskell. And maybe mostly because people learning Haskell do it by curiosity, so they'd like to explore the best way to do it, not being under their boss/client 's pressure.

yummyfajitas 17y ago

The Writer monad is better suited to logging than IO. http://www.haskell.org/all_about_monads/html/writermonad.html http://www.haskell.org/all_about_monads/html/writermonad.htm...