Functional programming has been around a long time, but it’s having a Renaissance lately. Why the sudden interest in functional programming?
One reason is that processors are not getting faster. Instead, we’re getting more of them. In order to get your results faster, you need to do more work at the same time. This is notoriously hard to do in procedural languages because you have to prevent separate computations from corrupting each other’s state. But with functional programming, this is a non-issue. Purely functional programs don’t have mutable state to corrupt. Programs that are mostly but not purely functional can quarantine the “impurity” to a small, well-marked part of the software so that most of the code can enjoy not worrying about mutable state.
Another reason that people are interested in functional programming, particularly strongly and statically typed functional programming, is that the compiler can assure you that your code is free of certain kinds of errors. Certainly not all errors, but many common families of errors. The assurances grow stronger over time as programmers learn to ask themselves “How can I write this so that the compiler will tell me I’m wrong if I make a mistake?” Functional programming does not eliminate the need for software testing, but it does allow software testing to be allocated strategically, concentrating on those errors that cannot be automatically detected.
Functional programming makes it easier to compose software components. By eliminating, or at least quarantining, side effects, functional programming makes it easier to know exactly what parts of the code could possibly impact other parts. Also, purely functional software composition is a mathematical problem, letting you take advantage of mature mathematical tools for understanding and guiding the composition.
Projects differ in how far they should go down the road to functional purity. Many projects benefit from applying a more functional programming style in their current environment. This gives some of the benefits of functional programming with minimal disruption. However, programmers are on a sort of “honor system” to abide by restrictions not verified by a compiler. Other projects may benefit from implementing key components in a purely functional language but orchestrating these components from a more conventional language. Still other projects may want to fully commit to functional programming. Every project has to weigh its own trade-offs.
If you’d like help deciding whether to move to functional programming, or help deciding how far you should go down the road to purely functional programming, we can help. Please call or email to discuss your project.
Trusted consultant to some of the world’s leading companies