Based on my own experience, I can’t offer much here. I have only used FP in production code at two positions: this one and the previous one. At the previous one, I was the source of FP advocacy, and it had a minimal effect by the time I left, pretty much an uphill battle the whole time. And at CollegeVine, FP was already in place when I arrived.Generally speaking, however, I can offer some observations and speculations:
Don’t do it just for fun. Find an actual application that would benefit from FP, even if marginally.
Don’t do it if a significant portion of the team is against it. This will just create a big disruption and result in extra distrust for FP in the future.
Don’t rewrite the world, or even part of it. Start with a small new feature or service written in an FP language.
Since the codebase will have to remain hybrid pretty much forever, really invest in the interface between FP language and whatever the rest of the codebase uses. A lot of friction will kill the whole thing.
Use a statically typed FP language, no matter what Rich Hickey tells you. :-)
Do not split the team into FP and non-FP. They will compete for resources.
We hope you enjoyed your interview with Fyodor!To read more interviews about the use of Haskell in production, head to our interviews section. And don’t forget to follow us on Twitter to stay updated about new articles!