In the last few years, functional programming (FP) languages and the ideas the languages implement have risen to prominence. This is partially due to various languages that contain some functional ideas becoming more mainstream (e.g., Ruby), and developers learning how to better leverage those functional features. It also helps that the .NET platform (particularly C#) has adapted and adopted many FP ideas and become more of a hybrid model. To further push things along, the Java platform (with Scala) and the .NET platform (with F#) now have full-featured languages that support the OO and FP paradigms at the same time; in .NET 4, F# is given the same weight as C# and VB.NET. Now that most developers have the ability to tap FP languages and concepts, when does it make sense to do so?
Here are a few things to keep in mind if you’re thinking about using FP:
- FP code does not have “side effects.”
- In FP, there are no literal values, simply functions that always return the same value.
- Many FP languages have “lazy evaluation,” where functions are not evaluated until their results are needed; in such a case, if you define “x” to be equal to “y + 5,” “x” will be defined with no value until you try to use the value of “x,” at which point execution returns to its definition, and the value is calculated and provided to the caller. This is a boon (better performance) and a curse (non-deterministic values in some cases) at the same time.
While none of these traits of FP languages should be considered hurdles, they do represent a radical change in thinking. You can leverage FP languages in ways that may dramatically improve the code writing process and the quality of code. However, if you FP languages, you need to be mindful that you aren’t overengineering or overthinking the problem, especially if it requires using a technique or a language that may confuse other code maintainers.
In my experience (which is limited when it comes to using FP in production code), I find that FP techniques and languages shine in algorithmic coding scenarios. Maybe I am stereotyping FP based on its “everything is a function” approach, but I find that FP works very well for that kind of work. Math, for example, is very nice in FP. A few months ago, I saw an F# sample where the author defined various units of measurement as functions that provided conversion, so you could add 10 meters and 45 inches in code perfectly naturally. Another impressive example of FP’s strength was the Xbox Live ranking system; it was rewritten from C# into F#, with about 10% of the total lines of code, and ran at 95% of the speed. Again, it is an example of algorithmic code.
Where FP loses its advantage is in the basic “library glue code” and creation of structure classes that constitutes much of the modern, mainstream software development experience. If your code consists of a lot of classes that look like structures, and most of your “algorithm code” is shuffling properties from one object to another, using FP just will not be worth the effort, unless your project is going to use it anyway.
In summary, FP is not necessarily the answer to all of your development challenges, but it is something worth checking out and seeing where it can fit into your toolbox.
Disclosure of Justin’s industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
Get weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic’s free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!