As IT professionals, we have to balance proficiently executing on current projects with proven technologies and learning to implement new ways of doing things. Software development arguably changes more rapidly than any other aspect of IT, making it an even tougher challenge.
Given the limited amount of time, it's often difficult to decide what new techniques to learn. The questions of if and where to use functional programming languages/techniques strikes me as one of the tougher calls to make these days.
If and where to use functional programming
First, let's define our terms. A functional language or technique is one in which the sole or dominant form of expressing algorithms is the evaluation of mathematical functions, avoiding state changes and mutable data. This is as against declarative, imperative, and procedural languages/techniques, which emphasize changes in state.
There is a strong case to be made that either functional languages or the other kinds can be object-oriented. LISP, considered by many an archetypal functional language, is a prime example. In other words, you can use either kind of language to implement object-oriented principals (and some would argue, more "purely" in functional languages). Similarly, you can write bad code in any language.
So, what kinds of problems are functional languages (if used well) superior at solving? Surveying the literature, problems that require lots of concurrency and parallelism jump out as obvious candidates. Erlang, for instance, was used prominently at Ericcson in the telecommunications equipment field, and more recently to power messaging startup WhatsApp. Interestingly, the famous Lucent (via Western Electric, not Bell Labs) 5ESS telephone switch is another example of a prominent functional programming success story. If you've placed a phone call to or in the United States in the last 30 years, chances are you used one of these devices, and the code that keeps its database (with more than 1,000 relations) consistent, was written in a custom language called Pdiff, which in turn was written in Standard ML.
That brings us to another area where functional languages seem to shine: domain specific languages (DSLs). If your problem domain is so hairy that the usual design patterns we're used to in typical enterprise languages like Java and C/++ fail to efficiently solve them, a DSL might be just the trick. You wouldn't build your whole system with a DSL, but, like the 5ESS switch, you could use it to code a critical function in a way that is easier to understand and maintain and, therefore, ensure its quality. Functional languages are killer at creating DSLs.
One interesting example I found is a DSL to process exotic financial derivatives. This illuminates another area where functional languages/approaches shine: math-heavy algorithms. If you need to solve a problem that can decompose into a series of mathematical operations, the kind of thing you'd tackle with a DSP chip or GPU, then a functional language is likely a good choice for expressing the solution.
Another way to think about this kind of problem is: Could you solve it, at a small-scale, with a spreadsheet? If the answer is yes, then you've got two choices: get a product that can compile spreadsheets into your platform of choice (many exist), or express it in a functional language. This is a useful analogy, because it highlights how functional languages (which seem so math-centric) can handle operations we're used to in other languages, like conditional statements. If you've ever used the IF function in a spreadsheet, then you have your answer. Functional languages, like the other kinds, are Turing Complete, and can be used to code any problem. The trick, it seems, is to code different parts of your system in languages that are most effective at expressing that part of the problem domain.
Great, so, I've got you interested in functional programming, now what the heck do you? When trying to build a new capability within my team, my preferred approach is to identify a potential pioneer. Someone who can grok the new ideas, drink the proverbial punch, and then bring that knowledge back to the team and evangelize. Send that person out for training, and then (as I think you should do with any training course) have them share what they learned with the team (buy them all a meal at the same time too, it helps). But only do so when you've identified a project or task where a functional approach makes sense. If folks don't start to use what they've learned within 30 days, it's likely gone.
If you want to incorporate functional code into your larger system, one approach is to have the language compile into the same bytecode as your main system; Scala runs on JVMs, and there is F# for the .NET CLR (and other platforms). You can always just run your code in one of the other functional language environments (such as Haskell, Clojure, OCaml, etc.) and expose it with a REST API as well.
The bottom line
If a project requires lots of concurrency/parallelism, its own language, or lots of math, think functional programming.
I'm coming at this issue from the perspective of someone who has been managing software development for over 20 years. I'm focusing on the questions: "Does this tool belong in my toolbox?" and "What kind of problems can I fix with it?" I hope the related discussion doesn't devolve into the near religious fervor that often accompanies discussions about which programming language is better for what application.
Also read on TechRepublic
Claudio Caballero is COO of Palomar Systems, a software development and systems integration firm in Bangkok, Thailand. Prior to returning to Asia from his native New York City, he was an IT consultant for 12 years, beginning as an Engagement Manager with B2B consultancy Lante in 1998, and most recently as a due diligence advisor to private equity firms. Mr. Caballero has been managing developers and engineers, and delivering complex IT and automation systems, for more than 20 years.