3 ms·

* For most real world use, laziness and performance don't even matter. That's definitely not a good reason. If you're an engineering leader and that's your argu

* For most real world use, laziness and performance don't even matter. That's definitely not a good reason. If you're an engineering leader and that's your argument for moving off Haskell for, say, a backend system..then you're either being disingenuous or are a bad decision maker. * The full compiles can be slow, but incremental compilation with ghci and cabal is never so awful in practice. And I've worked on some big projects. * I don't think the talent pool is especially shallow. I've never had trouble hiring Haskellers or finding a job as a Haskeller. If you broaden your scope to the Haskell-interested (and have teaching and learning core to your culture), it's even easier. I built some projects entirely with teams of new Haskellers. Went great.

dmitriid 5y ago
> If you broaden your scope to the Haskell-interested (and have teaching and learning core to your culture) So, first you have to hire quite senior Haskell engineers, and then at one point switch them to tracking Haskell to new hires. There aren't many companies who are willing to do that, and for a good reason.
- whateveracct 5y ago
  Training new hires in Haskell isn't a full-time job. Nor one only doable by senior engineers. I've had interns teaching interns, juniors teaching juniors, etc. Only prerequisite is a good attitude. If you start bean counting, you've already lost. If you think this level of software engineering cost optimization is necessary, you're just making your workplace worse.
  - dmitriid 5y ago
    > I've had interns teaching interns, juniors teaching juniors If those interns and juniors came to you knot knowing Haskell, then this is a very bad way of teaching people. You end up with bad, non-idiomatic code, poorly understood concepts etc. > If you start bean counting It's not bean counting.
    - whateveracct 5y ago
      We ended up with plenty of idiomatic code. They came in with 0 FP knowledge. Turns out you can learn the ropes & values in a couple months tops. Then you can learn with anyone and grow together. All the things you fear are barely consequential in practice in Haskell. All those things - who cares? What's the worst that can happen? The language puts such a high floor on the code it's okay. The main mistakes these newbies can make are stuff about database & distributed system design - orthogonal to Haskell and something they should be mentored on anyways.

dmitriid 5y ago

> If you broaden your scope to the Haskell-interested (and have teaching and learning core to your culture) So, first you have to hire quite senior Haskell engineers, and then at one point switch them to tracking Haskell to new hires. There aren't many companies who are willing to do that, and for a good reason.

whateveracct 5y ago
Training new hires in Haskell isn't a full-time job. Nor one only doable by senior engineers. I've had interns teaching interns, juniors teaching juniors, etc. Only prerequisite is a good attitude. If you start bean counting, you've already lost. If you think this level of software engineering cost optimization is necessary, you're just making your workplace worse.
- dmitriid 5y ago
  > I've had interns teaching interns, juniors teaching juniors If those interns and juniors came to you knot knowing Haskell, then this is a very bad way of teaching people. You end up with bad, non-idiomatic code, poorly understood concepts etc. > If you start bean counting It's not bean counting.
  - whateveracct 5y ago
    We ended up with plenty of idiomatic code. They came in with 0 FP knowledge. Turns out you can learn the ropes & values in a couple months tops. Then you can learn with anyone and grow together. All the things you fear are barely consequential in practice in Haskell. All those things - who cares? What's the worst that can happen? The language puts such a high floor on the code it's okay. The main mistakes these newbies can make are stuff about database & distributed system design - orthogonal to Haskell and something they should be mentored on anyways.