3 ms·
The 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
by plesn 17y ago
The 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...).
- coffee_dregs 17y agoplesn, 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 agoHow 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 agoCan 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 agoIt 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 agoHaskell nearly requires programmers to read papers each time they want to solve a new problem. Why is that?
- plesn 17y agoBecause 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 agoThe 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...
- dasil003 17y agoI'm really just beginning to learn Haskell while working professionally with Ruby. My gut instinct is that with Haskell you have to put in a lot of extra effort but you are repaid doubly in robustness. Obviously in real world scenarios there is a balance to be struck since a lot of code is just for throw-away purposes, or failure around edge cases does not affect the bottom line. However I suspect that the lack of traction Haskell gets in the commercial software world is more a result of human nature than actual economics of long-lived software projects. The reason I'm bullish on Haskell is because I suspect it can be a significant competitive advantage in a lot of the type of data processing scenarios that start out simple in a startup, but can become slow/buggy/unmaintainable over time.
- plesn 17y ago+1. I'm wondering what will be Haskell's killer app, aside GHC ;)