People that learn it tend to not want to use most other mainstream languages anymore, and thus want very badly it to grow.

I don't know what it is, but it does satisfy an itch. I took one class that used Haskell and ever since then I find myself missing it. I think something about writing in the functional mindset makes it easy to write "elegant" solutions.

Could it be because learning Haskell was such a major effort for them that they now don't want that to go to waste?

Learning Haskell (well) is a big investment. If you make that investment, of course you are going to argue that now we should reap the benefits of that investment.

It makes sense from the point of someone who has already made the investment of learning Haskell. But, choosing Haskell for a project means that other current and future programmers must make that same investment in leaning Haskell too, rather than learning something else perhaps. Or using what they already know well.

As someone who has hired many developers at a large Investment bank, I always found that people that knew Haskell or some other functional programming language tended to be far more productive in standard OO languages. I know of many other technical leads and hiring managers that look at Haskell as a market signal. As someone who does code in F# and Haskell in my spare time, I don't expect to get job using either of these languages, but knowing these languages got me a foot in the door to do some of the most interesting work I have ever had (many years ago). From those in the Haskell community that I do interact with, most people do not expect to code in Haskell for their day jobs, and most of them would continue writing Haskell code outside of work regardless of whether Haskell becomes a commercial success or not. For me, Haskell is one of those languages that is just worth knowing, simply because it gives you a different perspective on the world and a new set of mental tools. If you haven't as yet played with a strict functional language, then you really should give it a try.Not because you expect to use it at work, rather because learning new things is fun and it will make you better at your job anyway as a side effect. If the logic you used in your argument holds, then we should really be coding in assembler.

I've found the exact opposite. People i've worked with who are keen on Haskell have tended to be keen on building castles of unnecessary abstraction. People i've worked with who are not keen on Haskell are less so.

(Giuseppe, if you're reading this, you're the one exception!)

This sunk cost fallacy argument is easy to apply to many languages. Of the ones for which I've approached expert-level knowledge, C++ stands out as the one with the biggest sunk cost for the least gain. But let me tell you about my experience over the past couple years with OCaml, and why I think experts of Haskell, ML, and related languages are motivated by epiphany rather than sunk cost.

First, my CS background. I started programming in 1991, and have used dozens of languages major and minor over that time. At one time or another, I developed especially deep knowledge of the following: C, Perl, PostScript, Python, C++, and PHP. Functional languages always hovered at the edge of my interest, but never seemed practical enough to apply to the sorts of systems programming I love.

In 2017 I decided to spend some time broadening my understanding of language concepts, and made a list of languages to learn more about: OCaml, Julia, Clojure, Scala, Scheme, Haskell, Rust, Erlang, Go, Swift, and Kotlin. Learning OCaml ended up being such a transformative experience that I use it almost exclusively now. As an aside, I must say that it wasn't easy; it took the better part of a year to acquire the knowledge and experience necessary to feel productive.

Why is OCaml (and presumably Haskell) so good? The resulting programs feel like beautiful self-consistent crystalline structures rather than balls of mud. Furthermore, the powerful type system allows refactoring from one crystalline structure to another such that inconsistent hybrid crystals rarely occur. This is a much different experience from reshaping a ball of mud. The routine elegance and safety of these program representations aid in discovering the essences of solutions, and I have written programs I never would have discovered in other languages.

Killer features: - The powerful type system clarifies design, aids refactoring. - The module system (in combination with generics) enables truly modular design. - Effectless computation (pure functions, immutable data) simplifies reasoning about state.

I have some complaints about OCaml (and every other language I know), but it stands out as by far the most fulfilling to use. Going forward I will prefer to spend my programming time using languages more like OCaml, Haskell, Rust, etc. than those I used for the first 25 years.

It's not about "sunk cost". It's about making a new investment. How much would it cost to train all your programmers to be productive Haskell programmers?

Is it a worthwhile investment for your company? I'm not saying it isn't but that it is a big new investment if you're planning to make that transformation. Will it pay itself back in time? Maybe, maybe not. Or are there some other investments which would seem to have a bigger and less risky rate of return?

> How much would it cost to train all your programmers to be productive Haskell programmers?

Dunno about Haskell, but OCaml is way more simple than C++ or even Java. OCaml manual is 100 pages on informal tutorial + 100 pages of formal language definition. Another 200 pages are dedicated to runtime and tooling, and 400 more for the whole standard library.

With Java, the language manual itself is 800 pages, and that's without the library or runtime.

I don’t know Haskell so this is an abstract comment, but: effort put in is only a multiplier. If you put a lot of effort into something you despise, or that does not do the job, you will not be advocating it.

Thus, even if it is the case that it requires major effort, but people love its power, your word of caution is not really undermining the argument that it is a useful/powerful/enjoyable tool.

It's because Haskell is FUN to use (yes, with capitals and remark).

My guess it is actually more about silver bullet syndrome. Haskell seems great on the surface when you don't need to deal with state, order, memory constraints, memory layout etc. and can just focus on data flow problems.

I think people want programming in general to have that sort of simplicity, but data flow programming is already where focus can be on transforming data without the complexities of most real world programs.

I think there is a lot of desire to try to make Haskell work in all situations instead of what it is best at.

This is true of every technology.

Surely it must also be because Haskell is a pleasure to work with?

haskell extremely easy if it's your first language.

I suspect it makes people feel better about their work, because Haskell isn't so obviously flawed like most mainstream languages.

Let's talk in things that are more tangible. Haskell attempts to answer the question: "In the set of all possible programs that can be written to solve a certain problem domain how do I find the program that has the best modularity, best design and best safety?"

You would think that to answer the question above you would need a really expressive language. Haskell is a language that is actually less expressive and more restrictive than mainstream programming languages. You can be much more expressive in JAVA, C, C++, python, javascript and python then you can in haskell. For one you can mutate variables and re-assign them in mainstream languages and you can also have Loops. These things don't exist in Haskell.

Sounds really bad right? In actuality this is what makes haskell so powerful. Haskell is restricting the programmer to only be able to create a program that is much, much closer to answering the question above. The best design and the best modularity sort of exist has nebulous and instinctive concepts in most programmers. With haskell this concept comes closer to concreteness because Haskell simply doesn't allow you to write certain programs that are poorly designed or incorrect.

My first experience writing a non trivial haskell program was astonishing. Normally I program a little and test a little, then continuously add complexity to my programs through this iterative process of coding a little and testing a little.

With haskell I coded the entire program. Once it compiled it worked. No testing needed. I asked myself what was it that allowed me to do this in haskell? The answer was that it was because haskell prevented me from writing more programs that were incorrect. Errors and mistakes you would normally have to test for in other language can't even be compiled in Haskell. Nothing can totally eliminate testing but with haskell you can eliminate a huge portion of testing. So much so that programmers in haskell spend more time trying to get a program to compile than trying to test.

This power extends to refactoring. Most projects out there have problem domains that aren't fully defined and thus require refactoring changes in the future to better fit the problem domain. It's an inevitability. It often happens that such refactorings require massive and dangerous changes to code that has already accumulated immense complexity.

A common problem like this becomes trivial in haskell. Haskell forces your code to be modular so that such changes happen easily. The type system also ensures that if you do a change that is incorrect the compiler will catch it.

From a less tangible standpoint haskell also feels right. When you design things in other programming languages you're not sure where to cut your modules and how to correctly divide responsibility of your code and of course your mistakes become apparent over time. Haskell doesn't feel this way. It feels like the right approach to design and building primitives that snap together like legos. Over time this feeling will coalesce into understanding. You will completely understand why haskell programs are better designed then programs written in other languages.

I never mentioned performance. Although Haskell is very performant, haskell isn't suppose to answer the question of performance AND design (that's more rust) haskell just addresses design and safety. Additionally, it's not just haskell that has these qualities. It's actually the whole family of functional ML languages that haskell comes from that utilize Algebraic Data types and functional programming. You can achieve sort of the same philosophy I describe here by using something like Ocaml or Elm.

Also don't let the fact that haskell isn't mainstream put you off. Although it's not as practical, learning it is like taking the red pill. You'll never be the same.