5 ms·

Another Haskell post, another pron comment about how its community is misguided and wasting their time. I've solved production problems with Haskell (including

Another Haskell post, another pron comment about how its community is misguided and wasting their time. I've solved production problems with Haskell (including w/advanced type system features & dependent types). I will continue to do so. And I will probably write other commercial, money-making software for enterprises and for myself for years to come. I have plenty of experience programming in other languages. Clojure, Go, Java, Python. Haskell was the hardest to pick up. But now that I know it, writing other languages requires so much more energy in comparison. I barely have to try to deliver equal results compared to solving the same problems with other tools (so it's not a result of me just increasing my skill - the tool itself is a force multiplier for myself 100%)

hopia 7y ago
Yeah the the very first and by now a worn out dismissal you always see is it's an academic research language, not for writing REAL software. Out of interest, what kind of software do you build with Haskell? I'm doing web stuff and haven't quite been able to decide whether to stick to Haskell or Elixir for my own projects.
- whateveracct 7y ago
  Hm I'd describe it mostly as generic "backend engineering." Web services, databases, data processing, etc. I've used GHCJS as well but I mostly made small changes (I don't have frontend skills.) In my free time I'm making games in Haskell, but that's slow-going partially due to the ecosystem not being mature but mostly due to lack of free time :)
pron 7y ago
> I've solved production problems with Haskell What I said was that Haskell's design and evolution have been primarily guided by research questions rather than business needs, not that it's unsuitable for production use. I didn't say it's unsuitable for production use, nor do I think it. That doesn't change the pretty obvious fact that its features are mostly guided by research questions. > barely have to try to deliver equal results compared to solving the same problems with other tools (so it's not a result of me just increasing my skill - the tool itself is a force multiplier for myself 100%) If that effect were scalable and largely universal, then there would be no need for this discussion, anyway. But if it works well for you and the other thousands of developers who make up ~0.06% of the market, then it's great that it's available. Research languages also serve a very valuable goal in figuring out what works and what doesn't. If no one used them, we wouldn't know.
- rowanG077 7y ago
  Which Haskell design decision flies in the face of production use or what kind of feature would you like you to see in Haskell that isn't picked up due to it being an academic language?
  - travmatt 7y ago
    I’ve not used Haskell (so I have no idea of the validity) but the criticism I always hear leveled in discussions is that lazy evaluation makes runtime hard to reason about.
    - smitty1e 7y ago
      Haskell involves significant unlearning of imperative approaches. 99 bottles of beer with state monads gets at some of the challenge for the neophyte: http://www.99-bottles-of-beer.net/language-haskell-1360.html http://www.99-bottles-of-beer.net/language-haskell-1360.html Look at the struggle going on to deal with a "simple" piece of state.
      - lgas 7y ago
        That's not a particularly great example though because 99 bottles of beer is not a particularly stateful computation. You could easily do it without state at all like this: https://gist.github.com/lgastako/2e7dfd6b1118bb408ff114a4be46eac9 https://gist.github.com/lgastako/2e7dfd6b1118bb408ff114a4be4... On the other hand this blog post http://www.haskellforall.com/2013/05/program-imperatively-using-haskell.html http://www.haskellforall.com/2013/05/program-imperatively-us... demonstrates how one of the bits of Haskell that some people find complex (lenses) can be used together with the state monad to provide an "imperative-like" experience that's even nicer than most imperative languages.
        smitty1e 7y ago
        There were other examples, but figuring out how to deal with state is the most arcane and mystical aspect of haskell.

hopia 7y ago

Yeah the the very first and by now a worn out dismissal you always see is it's an academic research language, not for writing REAL software. Out of interest, what kind of software do you build with Haskell? I'm doing web stuff and haven't quite been able to decide whether to stick to Haskell or Elixir for my own projects.

whateveracct 7y ago
Hm I'd describe it mostly as generic "backend engineering." Web services, databases, data processing, etc. I've used GHCJS as well but I mostly made small changes (I don't have frontend skills.) In my free time I'm making games in Haskell, but that's slow-going partially due to the ecosystem not being mature but mostly due to lack of free time :)

pron 7y ago

> I've solved production problems with Haskell What I said was that Haskell's design and evolution have been primarily guided by research questions rather than business needs, not that it's unsuitable for production use. I didn't say it's unsuitable for production use, nor do I think it. That doesn't change the pretty obvious fact that its features are mostly guided by research questions. > barely have to try to deliver equal results compared to solving the same problems with other tools (so it's not a result of me just increasing my skill - the tool itself is a force multiplier for myself 100%) If that effect were scalable and largely universal, then there would be no need for this discussion, anyway. But if it works well for you and the other thousands of developers who make up ~0.06% of the market, then it's great that it's available. Research languages also serve a very valuable goal in figuring out what works and what doesn't. If no one used them, we wouldn't know.

rowanG077 7y ago
Which Haskell design decision flies in the face of production use or what kind of feature would you like you to see in Haskell that isn't picked up due to it being an academic language?
- travmatt 7y ago
  I’ve not used Haskell (so I have no idea of the validity) but the criticism I always hear leveled in discussions is that lazy evaluation makes runtime hard to reason about.
  - smitty1e 7y ago
    Haskell involves significant unlearning of imperative approaches. 99 bottles of beer with state monads gets at some of the challenge for the neophyte: http://www.99-bottles-of-beer.net/language-haskell-1360.html http://www.99-bottles-of-beer.net/language-haskell-1360.html Look at the struggle going on to deal with a "simple" piece of state.
    - lgas 7y ago
      That's not a particularly great example though because 99 bottles of beer is not a particularly stateful computation. You could easily do it without state at all like this: https://gist.github.com/lgastako/2e7dfd6b1118bb408ff114a4be46eac9 https://gist.github.com/lgastako/2e7dfd6b1118bb408ff114a4be4... On the other hand this blog post http://www.haskellforall.com/2013/05/program-imperatively-using-haskell.html http://www.haskellforall.com/2013/05/program-imperatively-us... demonstrates how one of the bits of Haskell that some people find complex (lenses) can be used together with the state monad to provide an "imperative-like" experience that's even nicer than most imperative languages.
      - smitty1e 7y ago
        There were other examples, but figuring out how to deal with state is the most arcane and mystical aspect of haskell.