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.