Functional Programming In C#

Introduction

Today, functional programming (FP) is no longer brooding in the research departments of universities; it has become an important and exciting part of mainstream programming.

The majority of the languages and frameworks created in the last decade are functional, leading some to predict that the future of programming is functional. Meanwhile, popular object-oriented languages like C# and Java see the introduction of more functional features with every new release, enabling a multiparadigm programming style. And yet, adoption in the C# community has been slow.

Why is this so? One reason, I believe, is the lack of good literature:

■ Most FP literature is written in and for functional languages, especially Haskell. For developers with a background in OOP, this poses a programming-language barrier to learning the concepts. Even though many of the concepts apply to a multiparadigm language like C#, learning a new paradigm and a new language at once is a tall order.

■ Even more importantly, most of the books in the literature tend to illustrate functional techniques and concepts with examples from the domains of mathematics or computer science. For the majority of programmers who work online-of-business (LOB) applications day in and day out, this creates a domain gap and leaves them wondering how relevant these techniques may be for real-world applications. xviii PREFACE These shortcomings posed major stumbling blocks in my own path to learning FP. After tossing aside then the book that explained something known as currying by showing how the add function can be curried with the number 3, creating a function that can add 3 to any number (can you think of any application where this would be even remotely useful?), I decided to pursue my own research path.

This involved learning half a dozen functional languages (some better than others) and seeing which concepts from FP could be effectively applied in C# and in the kind of applications most developers are paid to write, and it culminated in the writing of this book.

This book bridges the language gap for C# developers by showing how you can leverage functional techniques in this language. It also bridges the domain gap by showing how these techniques can be applied to typical business scenarios.

I take a pragmatic approach and cover functional techniques to the extent that they’re useful in a typical LOB application scenario, and dispense with most of the theory behind FP. Ultimately, you should care about FP because it gives you the following:

■ Power: This simply means that you can get more done with less code. FP raises the level of abstraction, allowing you to write high-level code while freeing you from low-level technicalities that add complexity but no value.

■ Safety: This is especially true when dealing with concurrency. A program written in the imperative style may work well in a single-threaded implementation but cause all sorts of bugs when concurrency comes in. Functional code offers much better guarantees in concurrent scenarios, so it’s only natural that we’re seeing a surge of interest in FP in the era of multicore processors.

■ Clarity: We spend more time maintaining and consuming existing code than writing new code, so it’s important that our code be clear and intention-revealing. As you learn to think functionally, achieving this clarity will become more natural.

If you’ve been programming in an object-oriented style for some time, it may take a bit of effort and willingness to experiment before the concepts in this book come to fruition. To make sure learning FP is an enjoyable and rewarding process, I have two recommendations:

■ Be patient: You may have to read some sections more than once. You may put the book down for a few weeks and find that when you pick it up again, something that seemed obscure suddenly starts to make sense.

■ Experiment in code: You won’t learn unless you get your hands dirty. The book provides many examples and exercises, and many of the code snippets can be tested in the REPL. Your colleagues may be less eager to explore than you.

Expect them to protest your adoption of this new style and to look perplexed at your code and say things like, “why not just do x?” (Where x is boring, obsolete, and usually harmful). Don’t discuss. Just sit back and watch them eventually turn around and use your techniques to solve issues they run into again and again.