8 ms·

I am interested in functional programming. Without a CS background I was wondering, if Haskell can provide these guarantees, why is it not more adopted? If, on

I am interested in functional programming. Without a CS background I was wondering, if Haskell can provide these guarantees, why is it not more adopted? If, on an enterprise scale, you can avoid the majority of bugs, would that not be a clear win?

dunefox 5y ago
> why is it not more adopted? "We use Java here. We have always used Java here and we will always use Java here. We're a Java shop. No other languages exist." My personal experience with companies. > If, on an enterprise scale, you can avoid the majority of bugs, would that not be a clear win? Yes, but then you wouldn't be using Java.
- nesarkvechnep 5y ago
  Yeah... the Java monoglots.
- yen223 5y ago
  I don't find this particular argument compelling, because there are other languages (e.g. Python and Golang) that have managed to make their way into the mainstream despite facing the same "we only use Java" challenge that hurts Haskell's adoption.
  - dunefox 5y ago
    Yes, Go, the Google language. Very surprising that it became mainstream. In the case of Python: it's imperative and somewhat object oriented and mostly without advanced features which makes it attractive for university courses, for example. Also sometimes languages just become popular, perhaps due to a certain library or sheer luck. That doesn't make it false for languages like Haskell.
    - yen223 5y ago
      > Yes, Go, the Google language. Very surprising that it became mainstream. It sure is. Dart, also a Google language, did not fare quite as well.
dudul 5y ago
It is hard to hire developers with Haskell XP since not a lot of companies use it. And not a lot of companies use it because it's hard to hire for. This vicious cycle exists for a lot of very good languages.
- jim-jim-jim 5y ago
  I think the solution is to stop looking for people with explicit experience in Haskell (or any lang), and to simply take on friendly and open-minded individuals to be trained internally. Even cleverness doesn't have to be a criterion; if you're doing FP right, you shouldn't need to be too smart. I'm certainly not. I was fortunate enough to be hired in this manner, and I'm always more than happy to help train up new members in a similar fashion. It pays off in the long run—and the short run too, since it doesn't take that long to get somebody playing with Maybes and Eithers in some internal module.
  - dmitriid 5y ago
    > simply take on friendly and open-minded individuals to be trained internally. "simply". So, you have to hire senior Haskell devs and then switch them to teaching new hires. See how this isn't feasible for most companies?
    - jim-jim-jim 5y ago
      Production and training aren't a binary. It's realistic enough to have a couple of senior devs write the scaffolding that segregates the nasty details, then have junior devs pair with them on the more logically pure modules. As long as you don't work for sweatshop that expects delivery on day one, it's no biggie at all. I've been on both sides of the equation and it works quite well in the long run.
      - dudul 5y ago
        Playing devils advocate: sounds pretty complicated. We'll just use Javascript and have access to an ever growing pool of cheap devs. Not saying your approach isn't reasonable, but c suite execs are not always reasonable, and it may be hard to justify this whole setup just to use language X.
08-15 5y ago
If Betamax is so much better than VHS, why is VHS a market success and Betamax a failure?
sullyj3 5y ago
Mostly because it takes a lot of patience and dedication to get to a productive level. It's a bit like vim - steep learning curve, but fantastic to use once you know what you're doing.
dmitriid 5y ago
Because the guarantees are largely exaggerated, require you to use specific language extensions (that you have to find out about somehow), and are often presented in a largely esoteric manner. Yes, you can write some advanced type-fu to provide interesting guarantees on the type level. But by the time you've learned how to do that, your colleagues will have delivered multiple projects in most other languages with test suites that provide similar guarantees.

dunefox 5y ago

> why is it not more adopted? "We use Java here. We have always used Java here and we will always use Java here. We're a Java shop. No other languages exist." My personal experience with companies. > If, on an enterprise scale, you can avoid the majority of bugs, would that not be a clear win? Yes, but then you wouldn't be using Java.

nesarkvechnep 5y ago
Yeah... the Java monoglots.
yen223 5y ago
I don't find this particular argument compelling, because there are other languages (e.g. Python and Golang) that have managed to make their way into the mainstream despite facing the same "we only use Java" challenge that hurts Haskell's adoption.
- dunefox 5y ago
  Yes, Go, the Google language. Very surprising that it became mainstream. In the case of Python: it's imperative and somewhat object oriented and mostly without advanced features which makes it attractive for university courses, for example. Also sometimes languages just become popular, perhaps due to a certain library or sheer luck. That doesn't make it false for languages like Haskell.
  - yen223 5y ago
    > Yes, Go, the Google language. Very surprising that it became mainstream. It sure is. Dart, also a Google language, did not fare quite as well.

dudul 5y ago

It is hard to hire developers with Haskell XP since not a lot of companies use it. And not a lot of companies use it because it's hard to hire for. This vicious cycle exists for a lot of very good languages.

jim-jim-jim 5y ago
I think the solution is to stop looking for people with explicit experience in Haskell (or any lang), and to simply take on friendly and open-minded individuals to be trained internally. Even cleverness doesn't have to be a criterion; if you're doing FP right, you shouldn't need to be too smart. I'm certainly not. I was fortunate enough to be hired in this manner, and I'm always more than happy to help train up new members in a similar fashion. It pays off in the long run—and the short run too, since it doesn't take that long to get somebody playing with Maybes and Eithers in some internal module.
- dmitriid 5y ago
  > simply take on friendly and open-minded individuals to be trained internally. "simply". So, you have to hire senior Haskell devs and then switch them to teaching new hires. See how this isn't feasible for most companies?
  - jim-jim-jim 5y ago
    Production and training aren't a binary. It's realistic enough to have a couple of senior devs write the scaffolding that segregates the nasty details, then have junior devs pair with them on the more logically pure modules. As long as you don't work for sweatshop that expects delivery on day one, it's no biggie at all. I've been on both sides of the equation and it works quite well in the long run.
    - dudul 5y ago
      Playing devils advocate: sounds pretty complicated. We'll just use Javascript and have access to an ever growing pool of cheap devs. Not saying your approach isn't reasonable, but c suite execs are not always reasonable, and it may be hard to justify this whole setup just to use language X.

08-15 5y ago

If Betamax is so much better than VHS, why is VHS a market success and Betamax a failure?

sullyj3 5y ago

Mostly because it takes a lot of patience and dedication to get to a productive level. It's a bit like vim - steep learning curve, but fantastic to use once you know what you're doing.

dmitriid 5y ago

Because the guarantees are largely exaggerated, require you to use specific language extensions (that you have to find out about somehow), and are often presented in a largely esoteric manner. Yes, you can write some advanced type-fu to provide interesting guarantees on the type level. But by the time you've learned how to do that, your colleagues will have delivered multiple projects in most other languages with test suites that provide similar guarantees.