Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

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

As you can see, it’s a bit of an uphill battle sometimes to explain the benefits of functional programming, especially more pure styles.  As part of this process, we can start to discuss not only the benefits of functional programming, but also how OOP and FP styles can work together to make your programs more declarative.  I hope some will be inspired enough to come to the session.  I have plenty of examples that I intend to post to either my Functional C# library on MSDN Code Gallery, or to another project with some F# samples.

This entry was posted in ALT.NET, C#, Conferences, F#, Functional Programming. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://podwysocki.codebetter.com Matthew.Podwysocki

    @Gabriel,

    Well, I hope this will be an interactive discussion and not just preaching from on high. To be very pragmatic about where it fits best.

    Matt

  • Gabriel Schenker

    functional programming has been one of the topics discussed at the first alt.net conference in the german speaking part of Europe last weekend (at Leipzig). But unfortunately we had no one like YOU to put some light into this topic. So we only scratched the surface. I’ll certainly try to attend your session. See you soon.

  • http://podwysocki.codebetter.com Matthew.Podwysocki

    @Justice,

    I promise not to be the most metro presentation, so I hope you’d find it palpable. As I’ve said above, I’m hoping to help bridge that gap that exists between the OOP and FP world. Should be a fun session either way.

    Matt

  • http://podwysocki.codebetter.com Matthew.Podwysocki

    @jdn

    I’ll see what I can do to record this. Remember that pure functional code is going to be a bit different than your typical OOP style of coding. What I’m going to approach with this session is how to influence your current designs with functional programming, as its not really realistic for most people to drop their current language and do things in a pure functional manner. But, I can build that bridge to help get you there to where you realize your side effects, manage them, and make your code more concise.

    Matt

  • http://graysmatter.codivation.com Justice~!

    If you record this, I will be your FRIEND FOR LIFE.

    From hearing Tom Opgenorth & Donald Belcham talk about it, it sounded like KaizenConf was just going to be a bunch of dudes sitting around, holding hands and french kiss each other; *that* I’m not into. However, this session would’ve actually gotten me to overlook that factor just so I could listen in!

  • http://www.blogcoward.com jdn

    I hope you record this session.

    ‘Immutable by default’ is a concept that I get on a conceptual level (no longer have to worry about shared state? sign me up), but because I am so ‘object/class-centric’ I think about something normal like a shopping cart, and get confused about even basic applications (so, everytime I want to change my shopping cart, I clone the object and apply the changes in the cloning? is that how it works?).

    Not that I’m requesting you do it, but a simple F# Shopping Cart example would probably help out the dullards like me who don’t yet grok the paradigm shift.