KaizenConf - Functional Programming – Is it a game changer?

Next week at the "Continuous Improvement in Software Development Conference" (KaizenConf), I will be giving a session called "Functional Programming - Is it a game changer?".  In this discussion, I'll cover the basics of functional programming, moving from an imperative style to a functional style, and what benefits you get from it.

Some of the topics to be covered are:

• What is Functional Programming?
• Why is it important?
• How does it affect our code?
• How can we get there?
• What roadblocks do we face?

It's a rather ambitious schedule to talk about these topics in a three hour timespan, but I'll do my best.  One of the more important topics is around how it affects your code, and can you mix and match OOP and FP.

How Does Functional Programming Affect Your Code?

Brian McNamara, of the F# team, posted "How does functional programming affect the structure of your code?" in which he talks about something that is near and dear to my heart.  There are three areas in which functional programming can affect your code, "in the large", "in the medium" and "in the small". 

Another name for "in the large" is high level design.  Here, functional programming has its least influence as we're too high up to really have any impact other than breaking into functionality and modules, which is true of any paradigm we choose.  At this level, we could talk about messaging architectures, where functional programming is well suited.  A mixture of OOP and FP using F#, or even C# can implement a wide array of possible solutions.  Laziness at this level can be a part of your architecture, only computing what is absolutely needed, instead of large blocking calls.

Moving onto "in the medium", we talk about the actual program structure of modules, classes, interfaces and so on.  For many applications, the OOP paradigm, with its classes/nouns first and methods/verbs second approach works nicely.  But, in other instances, such as some design patterns, where the need for classes is just noise.  For such such patterns as comparers, commands, strategy and others, classes aren't necessary, instead, simple functions will do.  Another important aspect of class design is mutability.  An immutable by default stance lessens the impact of shared state and its evils when it comes to moving towards parallel applications.

Then "in the small", we talk about the function/method level of our code.  At this level, this is where functional programming is most apparent.  Using high order functions to perform operations on your objects enable you to write more concise and compact code.  At this point, we're moving away from imperative code where we tell the machine how we want to do things, instead of what we want.  With the use of currying, recursion and other techniques, we're able to simplify our code and allow for more code reuse.

When we think about how it affects our code, it's best to look at all three levels in order to determine how our code can be affected by functional programming.  Using these techniques at each level can help simplify our code, especially in data intensive domains.

How Relevant Is It?

One topic that comes to bear frequently is, "How applicable is this to the standard Line of Business application developer?".  That question was asked once again on .NET Rocks Episode 388 with Uncle Bob Martin.  Bob was talking about how he has a tendency to follow the Pragmatic Programmers advice to learn a new language every year.  Recently, there has been a focus on functional languages with such languages as Haskell, Erlang, F#, Scala, and Common Lisp, so naturally there was a tendency to learn this paradigm.  Carl challenged that functional programming really isn't relevant to the line of business application developers.  Due to such things as immutable by default, Carl simply could not grasp the fact that with functional programming languages, that we could in fact write business applications, and in fact, write them fairly well.  There is a common misperception that resides out there that functional programming has and shall remain an academically geeky because it's a bit different way of thinking than our typical OOP nouns first, verbs second approach.  It's a large chasm to cross to get to this new way of thinking, and I'm hoping to cover that as part of this workshop.

Wrapping It Up