This is a tough situation that I think a lot of FP enthusiasts find themselves in. We are definitely seeing a rising tide of FP in software these days, but there’s still a long way to go.
I’d consider myself a polyglot developer. I love Haskell, but I’ve spent a lot of my career working in all sorts of other languages. I’ve learned a few hard lessons about introducing people to FP, and in particular Haskell, in the workplace.
Perhaps the most important piece of advice I can give is that, in my experience, writing functional with the hope that people will see how elegant it is almost never works. More often than not, people will become resentful and start to more actively reject FP on principle. I’ve definitely seen situations where someone who has been using Haskell for a while brings an idea over to another language, and it caused a rift on the team. In fact, my experience is that people are more likely to reject FP style code from someone they know is an FP enthusiast than they are to reject the same code from someone they don’t think of as a functional programmer. It’s a silly bias, and it won’t be that way everywhere, but I think it’s common enough that you have to address the possibility head on.
The second best piece of advice I can give is, under no circumstances, should you just write some code in Haskell and hope for the best. It’s a great way to have exactly one project in Haskell and to never be allowed to explore other languages in the workplace again. I think it’s a bad knee-jerk reaction teams have, but it’s the common reaction.
Here’s what works best in my own experience: Start by meeting the team where they are, and walk them through the motivation behind the ideas that you want to implement. Don’t present a solution- instead, introduce a series of problems. If you can get a PR in, and add incremental PRs to refactor something into a more functional style, with a clear explanation of what each change brings, and get some reviewers to buy in, that’s a good approach. If you have design or architecture meetings with your team, that’s another approach. Don’t say “let’s do FP”- just present a specific real problem in your code and then introduce a very practical fix that happens to borrow from a functional style. Once you’ve done that a few times, and helped people understand the problems you want to solve, and see the patterns for solutions, then you can talk about ways to abstract the ideas into something that borrows ideas from an FP language. Eventually, you might want to say “hey, we’re doing some stuff that is kind of FP style, maybe we should prototype this new feature in Haskell. If we do that, we’ll want to rewrite it in our main language when it goes to production, but it could be instructive.” and then offer to pair with people, write lots of documentation, or whatever else your team likes to do to share information. Maybe even have a reading group (this was another scenario I had in mind for Effective Haskell, and it’s why I spend so much time in the book trying to walk through the motivation behind particular features).
It’s a lot of work, and a lot of it requires paying attention to people’s feelings and the politics of the team as much as the technical motivations, but it can be done. I’ve never turned a team into an entirely Haskell team, but I have had broad team buy in on using Haskell for parts of a system, and had people who didn’t previously have much interest in FP become competent Haskellers able to contribute to that codebase. Not every team will be open to the idea, but a lot will when it’s approach the right way.
