The language is more restrictive and sometimes it's harder to get something working. Of course the payoff is immense, you end up with much more maintainable and composable code. However I'm not convinced that many enterprises care much about these properties, as they are often more of a long term win. People also have an emotional attachment to their existing tools and paradigms.
"Of course the payoff is immense, you end up with much more maintainable and composable code. However I'm not convinced that many enterprises care much about these properties, as they are often more of a long term win"
Actually, you have it backwards. Enterprises care a great deal about long term maintenance and have large codebases. However, they are also very conservative and prefer the tried and tested approach.
Startups don't typically care about maintenance because, for the most part, they are going for a binary win/lose outcome where in a win they have so many resources that 5x higher maintenance costs are ok, and in the lose they close up shop/pivot and throw the code out. And startups are usually more open to taking a chance on new/different tech.
If there were 3-4 large enterprise companies with 200kloc+ Haskell projects in use I feel Haskell could see long term 20-30% uptake in the enterprise. But few enterprises will take the risk of being one of the first.
> If there were 3-4 large enterprise companies with 200kloc+ Haskell projects in use I feel Haskell could see long term 20-30% uptake in the enterprise
I would be very surprised if there were not tens of companies with 200kloc+ Haskell codebases. I know that one of them is an enormous enterprise (but the others that I know of are not).
I never compared enterprises to startups. I also wouldn't want to generalise. Some enterprises I know have millions of lines of Python code. Personally I'm skeptical that such a codebase is going to be maintainable and that they even 'care a great deal'.
Very steep learning curve. Months to years to become good at it rather than the weeks to months of the Java/C# style enterprise languages. Needs a more "math like" mindset rather than a step-wise stateful mindset like typical imperative programming languages. If you're not good at abstract math you may never get comfortable with Haskell.
Have you seen C++14 or the complexity of Java stacks like Spring? These also take months or years to learn. At least learning some new abstract math is knowledge that will be useful for the rest of your life.
I agree with you and have said that in the past myself. However, most people know at least one imperative language already and that gives them a big step up in learning the frameworks. Learning Haskell is like starting over from scratch. And, at least for me, having completed an undergraduate hard science engineering degree, I'll never be good enough at math to really grok Haskell like I do many of the imperative languages. I'd make a rough guess, based on my observation, that for every 100 imperative programmers for whom the programming language just "flows" that only one or two will get that comfortable with Haskell.
IMHO if you are smart enough to complete an engineering degree you are easily smart enough to grok Haskell. It really is quite a simple language (compared to C++ and Scala anyway). Of course, like me, you might not grok everything that other people do with Haskell, but this is true for any language. I agree that Haskell is very different from imperative languages and that there can be a lot to learn before you can become productive.
Probably platform I would say. Hard to compete against languages that fit pretty naturally into an existing Java or .NET ecosystem. I'm referring to Scala, Clojure, and F# of course. It is definitely "popular" in some other senses though.
Let's have an honest conversation. Haskell is a great programming language. It might be the best. It is not going to get more than a 20% market share in the programming community. It could get 1 percent, which is about 5 times what it has now (measured in available jobs) and 25 times what it had 5 years ago. It could get 5 percent. It might even get 15 percent.
Much of our industry is based on trend-chasing. This 25-year-old language that happens to be really good, but whose strongest proponents even admit that it will never have a dominant (25+ percent) market share like Java or Javascript or PHP, is not a shoo-in for "next dominant paradigm".
Functional programming may be the next important paradigm and we're seeing the best programmers and the most important work gravitate toward it, but it's never going to be the go-to tool for the business-driven Scrum engineering that seems to dominate the mainstream of software.
What I would like to see happen is less use of general purpose programming languages; and more use of domain specific languages. DSLs give less opportunities for people to shoot themselves in the foot and more possibilities for heterogeneous hardware, parallel programming, static analysis etc. Of course, a small percentage of us will have to write these DSLs and Haskell IMHO is currently the best tool for this.