Reflections on leaving Haskell
alsonkemp.com
Reflections on leaving Haskell
1–10 of 24 posts
Re: Reflections on leaving Haskell
#2"And without Haskell I would be trapped in Scala-land, writing syntax-sugared-Java, confused about why functional programming was so great…"
Re: Reflections on leaving Haskell
#3The reasons against Haskell in this article are quite shallow and he would benefit from more knowledge (Why putting functions in the IO Monad to log/write stuff ??).
Real reasons I have against Haskell are it's complexity: compare it to the average readability of Python. Often, to resolve a tough problem, you have to upgrade your "level", which can be considered good (you tend to resolve it in an intellectually satisfying way) or bad (others have to understand it...).
Re: Reflections on leaving Haskell
#4The reasons against Haskell in this article are quite shallow and he would benefit from more knowledge (Why putting functions in the IO Monad to log/write stuff ??). Real reasons I have against Haskell are it's complexity: compare it to the average readability of Python. Often, to resolve a tough problem, you have to upgrade your "level", which can be considered good (you tend to resolve it in an intellectually satis…
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
Re: Reflections on leaving Haskell
#5The reasons against Haskell in this article are quite shallow and he would benefit from more knowledge (Why putting functions in the IO Monad to log/write stuff ??). Real reasons I have against Haskell are it's complexity: compare it to the average readability of Python. Often, to resolve a tough problem, you have to upgrade your "level", which can be considered good (you tend to resolve it in an intellectually satis…
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.…
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.
Re: Reflections on leaving Haskell
#6The reasons against Haskell in this article are quite shallow and he would benefit from more knowledge (Why putting functions in the IO Monad to log/write stuff ??). Real reasons I have against Haskell are it's complexity: compare it to the average readability of Python. Often, to resolve a tough problem, you have to upgrade your "level", which can be considered good (you tend to resolve it in an intellectually satis…
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.…
"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...
Re: Reflections on leaving Haskell
#7Earlier quoted context omitted.
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.…
"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 do…
Haskell nearly requires programmers to read papers each time they want to solve a new problem.
Why is that?
Re: Reflections on leaving Haskell
#8Earlier quoted context omitted.
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.…
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.
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?
Re: Reflections on leaving Haskell
#9Earlier quoted context omitted.
"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 do…
Haskell nearly requires programmers to read papers each time they want to solve a new problem. Why is that?
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.
Re: Reflections on leaving Haskell
#10Earlier quoted context omitted.
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.
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?
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.