4 ms·

alternatively if you think writing haskell isn't monad acrobatics then you haven't written i/o heavy code.

jeremyjh 9y ago
I’ve written more than 40,000 lines of I/O heavy code. I had a phase where I felt this way, but really it is a learning issue and you get passed it.
- virtualwhys 9y ago
  > but really it is a learning issue and you get passed it. No wonder, all this time I've been thinking that with enough practice I'll finally grok monads, but no, one simply has to wait for the pass to be on target. SPJ, hit me in the numbers!
- jernfrost 9y ago
  See that is why I eventually decided against Haskell. There are just too few Haskell jobs so investing that amount of time from a career perspective makes little sense. That leaves hobby projects. And it just does not seem to make sense to me to spend that much time on a hobby, when you got plenty of other powerful languages you can learn in a fraction of the time and do more useful stuff with. As an academic project language it seems great, but for practical work I just don't see it. I can do a fair amount of functional programming in Swift and Julia, but still make useful stuff without without an huge mental investment. My life as a professional C++ programmer has made me very negative to anything involving unreasonable complexity.
  - jeremyjh 9y ago
    I agree with you. I don't regret the time I invested in Haskell but the payoff isn't obvious. C++ is a very different kind of complexity though, it is so easy to get burned by something that compiles but fails at run-time or is very inefficient due to an issue you didn't know you didn't understand. The Haskell compiler may make you want to throw your computer through a window but you won't think everything is fine when its not.
  - donovanm 9y ago
    I've found it quite practical for getting things done, there's a higher learning curve then something like python though. From a career perspective it's hard to recommend anything that isn't one of the top most used programming languages, I'm not sure Haskell or most functional programming languages can do anything about that though.
- sokoloff 9y ago
  Any good open source examples of I/O heavy Haskell code? I'm a rank beginner at Haskell, understand the very basics, but still feel handcuffed when I stray away from the textbook examples.
  - jose_zap 9y ago
    Here’s a relatively simple example of a CLI tool that is very IO heavy https://github.com/seatgeek/docker-build-cacher https://github.com/seatgeek/docker-build-cacher
    - sokoloff 9y ago
      Thanks!
axlprose 9y ago
It doesn't even necessarily have to be IO heavy, just Functor and Monad heavy. But even that is reasonable to deal with just using traverse/sequence, fold, and fmap usually.
kccqzy 9y ago
I’ve written 60,000+ lines of Haskell, some of which are fairly I/O heavy with low-level FFI, raw and unsafe pointer manipulation, etc. I/O heavy code looks just like any other imperative language: you do this, perhaps extract a result, then do that. In contrast in pure code people have more tendency to get into monad acrobatics, but excessive monad acrobatics is just code smell.

I’ve written more than 40,000 lines of I/O heavy code. I had a phase where I felt this way, but really it is a learning issue and you get passed it.

virtualwhys 9y ago
> but really it is a learning issue and you get passed it. No wonder, all this time I've been thinking that with enough practice I'll finally grok monads, but no, one simply has to wait for the pass to be on target. SPJ, hit me in the numbers!
jernfrost 9y ago
See that is why I eventually decided against Haskell. There are just too few Haskell jobs so investing that amount of time from a career perspective makes little sense. That leaves hobby projects. And it just does not seem to make sense to me to spend that much time on a hobby, when you got plenty of other powerful languages you can learn in a fraction of the time and do more useful stuff with. As an academic project language it seems great, but for practical work I just don't see it. I can do a fair amount of functional programming in Swift and Julia, but still make useful stuff without without an huge mental investment. My life as a professional C++ programmer has made me very negative to anything involving unreasonable complexity.
- jeremyjh 9y ago
  I agree with you. I don't regret the time I invested in Haskell but the payoff isn't obvious. C++ is a very different kind of complexity though, it is so easy to get burned by something that compiles but fails at run-time or is very inefficient due to an issue you didn't know you didn't understand. The Haskell compiler may make you want to throw your computer through a window but you won't think everything is fine when its not.
- donovanm 9y ago
  I've found it quite practical for getting things done, there's a higher learning curve then something like python though. From a career perspective it's hard to recommend anything that isn't one of the top most used programming languages, I'm not sure Haskell or most functional programming languages can do anything about that though.
sokoloff 9y ago
Any good open source examples of I/O heavy Haskell code? I'm a rank beginner at Haskell, understand the very basics, but still feel handcuffed when I stray away from the textbook examples.
- jose_zap 9y ago
  Here’s a relatively simple example of a CLI tool that is very IO heavy https://github.com/seatgeek/docker-build-cacher https://github.com/seatgeek/docker-build-cacher
  - sokoloff 9y ago
    Thanks!

axlprose 9y ago

It doesn't even necessarily have to be IO heavy, just Functor and Monad heavy. But even that is reasonable to deal with just using traverse/sequence, fold, and fmap usually.

kccqzy 9y ago

I’ve written 60,000+ lines of Haskell, some of which are fairly I/O heavy with low-level FFI, raw and unsafe pointer manipulation, etc. I/O heavy code looks just like any other imperative language: you do this, perhaps extract a result, then do that. In contrast in pure code people have more tendency to get into monad acrobatics, but excessive monad acrobatics is just code smell.