A few years ago I volunteered to do mock interviews for a bunch of students who were getting ready to graduate from a bootcamp. I didn't know much about the bootcamp curriculum and I was surprised to see that all of the resumes listed functional programming as one of the key skills. I was curious, and asked the first few interviewees about their experience with FP and they made up some nonsensical answers with varying degrees of confidence. I finally asked one of them to just tell me what functional programming was, and was and they said "oh, you know, writing a program that functions!".

I made it a point of telling the students that it's a lot better to admit you don't know something rather than making something up in an interview, and reached out to the founder of the bootcamp to express my disappointment that they were sending people into interviews with blatantly false experience on their resume. I'm not sure if anything ever came of it, and from time to time I wonder how many graduates from that bootcamp are still going out into interviews with no idea that "functional programming" means anything other than writing programs that function.

The company I work for is much smaller but we’ve still grown a lot with a nearly 100% Haskell codebase (on the backend at least). For us, the main thing has been setting expectations and doing a lot of upfront training and mentoring. We hire people who don’t know Haskell or who have never done FP and put them through training. We have a lot of mentoring ongoing afterwards.

I use Haskell at work. At my current job it’s my teams primary language, and almost all code we write is in Haskell. I’ve been using Haskell at work for years now, but more often as a secondary or tertiary language along side others.

Haskell, and FP generally, work well for everyday industrial programming. In my experience I’ve never found there to be an issue that was a dealbreaker- although there are tradeoffs.

That said, whenever I’ve looked for work I’ve always looked at non-FP roles in addition to FP roles because there are just fewer FP jobs out there.

I’ve heard it come up in talks as a curiosity but I’m not familiar with any concrete attempts to use it as a part of a course. I expect that most while on the whole excel might be the worlds most popular programming language, the overlap between people who are good enough at excel for it to benefit their learning, and the people who want to learn FP, is small enough that it would hinder more than help.

That said, my intuition could be totally wrong here and if someone does put something like that together I’d love to see if.

Another classic FP talk is Rich Hickey's Simple Made Easy. I think he does a great job of talking about the differences between things that are simple, and things that are merely easy.

This is pretty neat. For anyone else interested in this kind of thing you might want to take a look a comprehensive comprehensions. That paper looks at the related idea of embedding a more sql-like syntax into list comprehensions in Haskell.