But first, a brief introduction as to what prompted this line of posting. At PDC ‘09 I had the pleasure of making acquaintances with Jon Galloway and Steve Andrews who challenged me to do more than practice & talk with co-workers and put together a talk and the suggested topic for said talk was – functional programming. Well, I’m not quite at the talk stage yet, but figured that the blog format worked as a good starting point.
So, what is functional programming? Wikipedia offers the following definition, “In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state. Functional programming has its roots in the lambda calculus, a formal system developed in the 1930s to investigate function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus.” Distilled from Functional Programming for the Real World one is left with the following impression: that functional programming is a declarative style, it promotes immutability, cleaner code & logic organization, functions as data, function composition, and that it’s based on lambda calculus. That is a highly distilled version of some of the highlights from the first two chapters running about 50 pages. While both these sketches are accurate, they’re not necessarily helpful in understanding what it is.
At its essence functional programming is another set of tools in the developer’s kit. For the engineers it’s another hammer for a specific type of material, or a different spanner. For the artists, it’s another brush. But because we work outside the confines of the material world our tools aren’t as limited, similarly functional programming isn’t limited to one specific application. Functional programming is about three different types of tools:
- A different way of decomposing problems and coming up with solutions – rather than considering objects (data & actions), considering atomic transformations of data and how those fit together. For example, the pipelining of data in *nix scripts, DOS batch files, or PowerShell, or the IEnumerable extension methods taking in IEnumerable and returning IEnumerable
- A different way of organizing code to improve readability and comprehension – rather than organizing code around delimiters { } If/End If and classes, organizing around significant whitespace and the transformation to be performed
- A different language/syntax to better fit a different problem domain – sometimes it makes more sense to look at (F#)
1: /// The squares of the first 10 integers
2: let squaresOfOneToTen = [ for x in 0..10 -> x*x ]
compared with (C#)
1: List<int> squaresOfOneToTen = new List<int>();
2: for (int x = 0; x < 10; x++)
3: {
4: squaresOfOneToTen.Add(x * x);
5: }
Like all good tools of the craft, it’s about using the right tool for the right job and functional programming equips you with an array of tools from analysis and design down through code construction. Functional programming complements object-oriented and procedural programming quite well and is really about making your programs simpler and easier to maintain. Next up, simplifying and eliminating some duplicate code from a WCF example.