Hacker News Reader

Comment by StefanWestfal | Hacker News Reader

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?

View on HN

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

Yeah... the Java monoglots.

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.

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.

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

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.

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.

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.

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.

> 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?

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.

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.

It's not just "c-suite execs".

If our department has 60 devs across 5-10 teams, the cost of "simply" bringing in people who don't know the language and expecting to both onboard them to business and teach them a new language becomes astronomical

I guess I'm not just speaking in favor of language x, but a broader culture of knowledge sharing, pairing, and educational development that naturally supports languages like x. I realize this is anathema to slavedrivers, but it can and does work.

> As long as you don't work for sweatshop that expects delivery on day one, it's no biggie at all.

What about "a big company with multiple dev teams that are expected to actually deliver things on time"?

I work for a large firm (hundreds of engineering staff) that invested in strongly-typed FP. We deliver things on time because we're not putting out fires caused by stupid runtime errors. There's more than enough time to teach the juniors along the way too. Once again, education is a ultimately a facet of productivity, not something that detracts from it.

Which languages are you using if I may ask? I was looking at Haskell and Elm and some repositories show little activity. Was the ecosystem a problem for you?

Haskell, Scala, Typescript, and Purescript. Ecosystem is better with Scala, but hasn't been too much of a problem in any of them, perhaps because we try to avoid too many dependencies.

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

Reply on news.ycombinator.com