5 ms·

Evidence does not remain scant. For instance - ever used Starbucks Rewards? Congrats, you used Haskell software built by more than "two buddies." Ever shop at T

Evidence does not remain scant. For instance - ever used Starbucks Rewards? Congrats, you used Haskell software built by more than "two buddies." Ever shop at Target? Congrats, the inventory was likely in the store to fulfill your demand in part thanks to Haskell software built by a team. However, a large engineer org that brings in senior non-Haskeller engineers/managers/leadership is bound to run into political troubles imo. Those types tend to blame Haskell and use it as an excuse for rewriting and re-orging - hence giving them newfound power. This isn't FUD or a strawman. This is observed behavior of many "respected" "old heads" I've had to work with/for. That's just my experience from 3 different companies lol :) You can build software at any scale with Haskell - you just have to actually like and want to use Haskell for its cultural and technical benefits. 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. That's just facts.

WastingMyTime89 5y ago
> 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.
        5y ago

WastingMyTime89 5y ago

> 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.
      - 5y ago