The Functional Programming (FP) paradigm has been enjoying a resurgence in developer circles for more than five years now. Its advocates however have faced difficulty making the case for FP when management sits across the table. Usually, the typical FP advocacy piece drowns the business advantages of FP in technical terms, and the audience tunes out. In this article, we strive to avoid this pitfall and ground the case for FP in the real world of profitability and risk.
We at Solita at positioned well to make the necessary distinctions: We boast great experience in FP, we count FP among our software best practices and we advocate for FP to our customers.
If your business offers a software product or service, you care about quality. The connection between quality and your bottom line needs no explanation. Let’s proceed then to the connection between the quality of a software product and an FP codebase. It’s a fact of life that code is faulty. All but the most rigorously written code contains faults and the number of faults per line of code is, on average, constant1. The conclusion: more code, more faults. The FP solution to a problem is not only less code2 compared to the typical alternatives but also less fault-prone on a per-line-of-code basis3. We may safely state: FP, higher quality.
Time To Market
Managers of most software products treat time-to-market (TTM) as priority #1. The time developers need to complete a feature is the primary driver behind TTM. Moreover, the effort required to tackle a software project scales superlinearly, i.e. if project A is twice the size of project B, it requires more than twice the code4. With less code to write for features and less code to test them, it is safe to state: FP, reduced TTM.
Shrewd folks in the software business know that technology evolves very rapidly. They also know that being competitive is directly correlated to how well the business can keep up with these changes. One change that is here to stay is that getting better performance by buying faster processors is a thing of the past5. Steve Jobs, at the time, believed that the industry lacks the skills to address this crisis:
“The way the processor industry is going is to add more and more cores, but nobody knows how to program those things. I mean, two, yeah; four, not really; eight, forget it.” 6
These statements are a bit technical though, so let’s break them down. If you serve customers with a digital product, you are faced with a hard limit on how many customers you can serve per second. Any business which seeks to grow must have a strategy for pushing this limit upwards. Today, there is only one way to push that limit: write the software such that it scales. Such software though, is difficult to write in non-FP languages. The reason is that they encourage the sharing of computation state, an difficult thing to get right on a distributed system. By forbidding the sharing of state and by providing tools for mutating state explicitly, the FP paradigm has proven7 8 9 to be a much better fit for scalable software. It is, therefore, safe to state: FP, improved long-term growth.
In the software world, managers bemoan the difficulty of hiring FP developers. This difficulty is an undeniable fact. The keen manager however, also recognizes that this difficulty is just another trade-off. Let’s take a closer look at the stakes: FP developers are aware of the comparative scarcity of FP jobs. FP developers are perfectly capable of delivering OO software. The typical FP developer foregoes safe, abundant, high-paying OO jobs so that they may develop in their favorite paradigm. Any manager who considers FP may therefore expect to run a highly motivated and highly performing team. Hardly the kind which the drive-by headhunter will cripple during the most critical phase of development. You are safe to infer: FP, tight and loyal team.
FP adoption has been hindered by a number of misconceptions. Let’s set the record straight!
There are no libraries!
It depends on the language and the runtime. The most popular FP languages today run on the JVM and feature seamless Java interoperability. In other words: you may use any existing Java library you wish with them.
I don’t trust the runtime!
If the runtime is a concern, you have a wide selection of languages to choose from which are designed for battle-tested runtimes. Scala and Clojure run on the JVM, F# runs on the .NET CLR, Erlang and Elixir run on BEAM. All of these have proven their worth in production under extreme workloads10 11 12 and are actively maintained by large, reliable corporations.
I can’t reuse!
In today’s world of distributed computing, there is no excuse for complaining about performance without taking parallelism and scalability into account. If you develop performance-sensitive software for single-threaded execution, then FP might not be the right tool for you.
It’s only good for mathematicians and academics!
The many and varied success stories of FP adoption by industry disprove this. Be it networking13, messaging services14, finance15, insurance16 or web development17, FP languages are proving versatile and capable tools.
Functional Programming is a tool. A mature, stable and reliable tool with a track record reaching as far back as the ’80s. Nevertheless, not more than a tool and therefore only useful when applied to the right problem. From the business perspective, is safe to say that the current era of computing (i.e. distributed in a global scale) presents problems that are a good fit for this tool. Companies who succeed in putting FP teams together are on their way to building high-quality software and ensuring their long-term viability.
Steve McConnell (2004). Code Complete: A Practical Handbook of Software Construction, Second Edition. Microsoft Press. p. 521. ISBN 978-0735619678. ↩
Baishakhi Ray, Daryl Posnett, Vladimir Filkov, Premkumar Devanbu (Novermber 2014). A large scale study of programming languages and code quality in GitHub. FSE 2014: Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. ↩
Sebastian Nanz, Carlo A. Furia (August 2014). A Comparative Study of Programming Languages in Rosetta Code. Proceedings of the 37th International Conference on Software Engineering (ICSE’15), pages 778-788. IEEE. ↩
Steve McConnell (2006). Estimation: Demystifying the Black Art (Developer Best Practices). Microsoft Press. p. 56. 978-0735605350. ↩
Herb Sutter (March 30, 2005).The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software. Dr. Dobb’s Journal. ↩
John Markoff (June 10, 2008). Apple in Parallel: Turning the PC World Upside Down?. New York Times - Business, Innovation, Technology, Society. ↩
Joe Armstrong (August, 2014). Programming Erlang, Second Edition - Software for a Concurrent World. The Pragmatic Programmers. p. xiii. ISBN 978-1937785536. ↩
Peyton Jones, Andrew Gordon, Sigbjorn Finne (January 1996). Concurrent Haskell. Proceedings of the 23rd ACM Symposium on Principles of Programming Languages. ↩
Ricardo Terrell (July 17, 2018). Concurrency in .NET : Modern patterns of concurrent and parallel programming. Manning Publications. p. 23. ISBN 978-1617292996. ↩
Yan Cui - Lead Server Engineer at GameSys. The F# solution offers us an order of magnitude increase in productivity. F# Testimonials. ↩
Johan Bevemyr. How Cisco is using Erlang for intent-based networking. ↩
Grange Insurance. Grange Insurance parallelized its rating engine to take better advantage of multicore server hardware. F# Testimonials. ↩