4 ms·

> Sadly, a complainer at the top of the org chart who can't even read Haskell code can easily come in and force Haskell out. It’s a lazy language so estimating

> Sadly, a complainer at the top of the org chart who can't even read Haskell code can easily come in and force Haskell out. It’s a lazy language so estimating real world performance is hard. It has a slow compiler and a very shallow pool of talents. You don’t really need to be a complainer to think that removing it from your organisation code base is a step in the right direction if you are not an Haskell shop. I would do the same with Ocaml despite liking Ocaml.

DonaldPShimoda 5y ago
> I would do the same with Ocaml despite liking Ocaml. Ah yes, the language that's so famously bad at performance that its only noteworthy usage in industry is... a trading firm that needs to be able to handle data in microseconds to make money. If only they had chosen better.
- WastingMyTime89 5y ago
  The key point is the shallow pool of talents. JaneStreet definitely qualify as an Ocaml shop if you didn’t notice. It is an awesome language but I would never use it in a company which is not purely banking on it.
  - whateveracct 5y ago
    If you hire remote, the Haskell job market has plenty of good engineers ime.
whateveracct 5y ago
* 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.

DonaldPShimoda 5y ago

> I would do the same with Ocaml despite liking Ocaml. Ah yes, the language that's so famously bad at performance that its only noteworthy usage in industry is... a trading firm that needs to be able to handle data in microseconds to make money. If only they had chosen better.

WastingMyTime89 5y ago
The key point is the shallow pool of talents. JaneStreet definitely qualify as an Ocaml shop if you didn’t notice. It is an awesome language but I would never use it in a company which is not purely banking on it.
- whateveracct 5y ago
  If you hire remote, the Haskell job market has plenty of good engineers ime.

whateveracct 5y ago

* 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.