THE BEST PLACES TO USE FUNCTIONAL PROGRAMMING
FP can do absolutely anything that any other paradigm can, but there are areas where it’s
strongest and most beneficial - and other areas where it might be necessary to compromise
and incorporate some Object Orientation features, or slightly bend the rules of the Functional
Paradigm. In .NET at least, compromises necessarily have to be made, because any base
classes or add-on libraries all tend to be written following the Object-Orientated paradigm.
This doesn’t apply to Pure Functional languages.
Functional Programming is good where there’s a high degree of predictability. For example,
data processing modules - functions that convert data from one form to another. Business
logic classes that handle data from the user or database, then pass it on to be rendered
elsewhere. Stuff like that.
The stateless nature of Functional Programming makes it a great enabler of concurrent
systems - like heavily asynchronous codebases, or places where several processors are
listening concurrently to the same input queue. When there is no shared state, it’s just about
impossible to get resource contention issues.
If your team is looking into using Serverless applications - such as Azure Functions, then
Functional Programming enables that nicely for most of the same reasons.
It’s worth considering Functional Programming for highly business-critical systems because
the paradigm tends to produce code that is more stable and robust than applications coded
with the Object-Orientated paradigm. If it’s incredibly important that the system should stay
up, and not have a crash and burn (i.e. terminate unexpectedly) in the event of an unhandled
exception or invalid input, then Functional Programming might be the best choice.
Where You Should Consider Using Other Paradigms?
You don’t have to ever do any such thing, of course. Functional can do anything, but there
are a few areas where it might be worth looking around for other paradigms - purely in a C#
context. And it’s also worth mentioning again that C# is a hybrid language, so many
paradigms can quite happily sit side by side, next to each other, depending on the needs of the
developer. I know which I prefer, of course!
Interactions with external entities is one area for consideration. I/O, user input, 3rd party
applications, web APIs, that sort of thing. There’s no way to make those pure functions (i.e.
without side effects), so compromise is necessary. The same goes for 3rd party modules
imported from Nuget packages. There are even a few older Microsoft libraries that are simply
impossible to work with Functionally. This is still true in .NET Core. Have a look at the
SMTP features of C# and the MainMessage class if you want to see a concrete example.
In the C# world, if performance is your projects only, overwhelming concern, trumping all
others, even readability and modularity, then following the Functional paradigm might not be
the best idea. There’s nothing necessarily inherently poor in the performance of Functional
C# code, but it’s not necessarily going to be the most utterly performant solution either.
I would argue that the benefits of Functional Programming far outweigh any minor loss of
performance, and these days, most of the time it’s very easy to chuck a bit more hardware
(virtual or physical, as appropriate) at the app - and this is likely to be an order of magnitude
cheaper than the cost of additional developer time that would otherwise be required to
develop, test, debug and maintain the codebase that is written in imparative-style code. This
changes if - for example - you’re working on code to be placed on a mobile device of some
sort, where performance is critical, because memory is limited and can’t be updated.
How Far Can We Take This?
Unfortunately it simply isn’t possible to implement the entirety of the Functional paradigm in
C#. There are all sorts of reasons for that, including the need for backwards compatability in
the language and limitations imposed on what remains a strongly-typed language.
The intention of this book isn’t to show you how all of it can be done, but rather to show
where the boundaries are between what is and isn’t possible. I’ll also be looking into what’s
practical, especially with an eye to those of you maintaining a production codebase. This is
ultimately a practical,
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
var filmIds = new[]
{
4665,
6718,
7101
};
var filmsWithCast = filmIds.Select(x => ( film: GetFilm(x),
castList: GetCastList(x)
));
var renderedFilmDetails = filmsWithCast.Select(x =>
@$" Title: {x.film.Title}
Director: {x.film.Director}
Cast: {string.Join(", ", x.castList)} ".Trim());
In my example, above, I use a Tuple to pair up data from two look-up functions for each
given film Id, meaning I can run a subsequent Select to simplify the pair of objects into a
single return value.
Iterator value is required
There’s one final tricky case I’d like to cover here. What if you’re Select-ing an Enumerable
into a new form, and you need the iterator as part of the transformation. Something like this:
var films = GetAllFilmsForDirector("Jean-Pierre Jeunet")
.OrderByDescending(x =>
x.BoxOfficeRevenue);
var i = 1;
Console.WriteLine("The films of visionary French director");
Console.WriteLine("Jean-Pierre Jeunet in descending order"
Console.WriteLine(" of financial success are as follows:");
foreach (var f in films)
{
Console.WriteLine($"{i} - {f.Title}"); i++;
}
Console.WriteLine("But his best by far is Amelie");
We’re iterating through a list of complex objects that’s already been ordered by Linq, so we
can’t use the Enumerable.Range trick here. Even a Tuple won’t do, because we’d need a way
to join the two arrays together. To make
it worse, you don’t know how long an Enumerable is until it’s enumerated, so we wouldn’t
even know how long to make our Range list.
Instead we can use a feature of Select statements that surprisingly few people know about -
that it has an override that allows us access to the iterator as part of the Select. All you have
to do is provide a Lambda expression with 2 parameters, the second being an integer which
represents the index position of the current item.
This is how our functional version of the code looks:
var films = GetAllFilmsForDirector("Jean-Pierre Jeunet")
.OrderByDescending(x =>
x.BoxOfficeRevenue);
Console.WriteLine("The films of visionary French director");
Console.WriteLine("Jean-Pierre Jeunet in descending order"
Console.WriteLine(" of financial success are as follows:");
var formattedFilms = films.Select((x, i) => $"{i} -
{x.Title}"); Console.WriteLine(string.Join(Environment.NewLine,
formattedFilms));
Console.WriteLine("But his best by far is Amelie");
Using these techniques, there’s nearly no circumstance that could exist where you need to use
a For or ForEach loop with a List. Thanks to C#’s support for the Functional paradigm, there
are nearly always Declaritive methods available to solve problems.
The two different methods of getting the “i” index position variable are a great example of
Imperative vs Delarative code. The Imperative, Object- Orientated method has the developer
manually creating a variable to hold the value of i, and also explicitly set the place for the
variable to be incremented. The declaritive code isn’t concerned with where the variable is
defined, or in how each index value is determined.
There are ways to take this further still, but for this chapter I’m sticking to the relatively
simple cases, ones that don’t require hacking around with C#. This is all out-of-the-box
functionality that anyone can use right away.
N.b - Notice that I used string.Join to link the strings together. This is not only another one of
those hidden gems of the C# language, but it’s also an example of Aggregation, that is -
converting a list of things into a single thing. That’s what we’ll walk through in the next few
sections.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
Pragmatic guide to Functional coding styles.
Monads – Actually don’t worry about this yet
Monads are often thought to be the Functional horror story. Look on Wikipedia for
definitions, and you’ll be presented with a strange letter soup containing Fs, Gs, arrows and
more brackets than you’ll find under the shelves of your local library. The formal definitions
are something I find - even now - utterly illegible. At the end of the day, I’m an engineer, not
a mathematician.
Douglas Crockford once said that the curse of the Monad is that the moment you gain the
ability to understand it, you lose the ability to explain it. So I won’t. They might make their
presence known somewhere in this book, however. Especially at unlikely times.
Don’t worry, it’ll be fine. We’ll work though it all together. Trust me…
Summary
In this first exciting installment of Functional Programming with C#, our mighty, awe-
inspiring hero - you - bravely learned just what exactly Functional Programming is, and why
it’s worth learning.
There was an initial, brief introduction to the important features of the Functional paradigm:
Immutabilty
Higher-Order Functions
Prefer Expressions over Statements Referential Transparency
Recursion
Pattern Recognition
Stateless
There was a discussion of the areas Functional Programming is best used in, and where
perhaps a discussion needs to be had regarding whether to use it in its pure form or not.
We also looked at the many, many benefits of writing applications using the Functional
Paradigm.
In the next thrilling episode, we’ll start looking at what you can do in C# right here, right
now. No new 3rd party libraries or Visual Studio extension required. Just some honest-to-
goodness out-of-the-box C# and a little ingenuity.
Come back just over the page to hear all about it. Same .NET time. Same
.NET channel12.
1 including Vanilla, and my personal favorite - Banana
2 They were Hero turtles when I was growing up in the UK in the 90s. I think
the TV people were worried we’d hear the word “ninja” and go on the rampage or something!
3 Credit must be given to functional programming supremo Mark Seeman for
giving me these rules of thumb.
4 Ok, art bods, I know there are actually about 12, but that’s more than I need
for this metaphor to work
5 Never do this particular example in production code. I’m keeping it simple for
the purposes of explanation
6 with a little creative liberty taken
7 available to read online for free at http://www.learnyouahaskell.com. Tell ‘em
I sent you
8 Although I am learning Latin. I’m a nerd. It’s the sort’ve thing I do for fun.
9 especially F# guru Ian Russell, who helped with the F# content in this book.
Thanks, Ian!
10 at least that’s what we tell our managers
11 virtual or otherwise
12 or book, if we’re being picky
Part I. What Are We Already Doing?
Believe it or not, there’s a good chance you’ve been doing functional coding to a greater or
lesser extent if you’ve been coding with .NET for any amount of time.
This first part is all going to be about showing you just how much of your everyday code is -
or could easily be - functional. All of this without installing a single library beyond those
provided by Microsoft. No tricky theory either.
Think of this section as the shores of our journey to the wet, dark, mysterious depths of
functional programming. You’re still on dry land, and everything should feel vaguely
familiar.
Part Two is where we’ll start looking more into functional concepts. If you’re finding Part
One too easy as you’re reading, then feel free to skip ahead to Part Two.
Chapter 2. What can we do already?
In this chapter, I’m going to look at the Functional Programming features that are possible in
just about every C# codebase in use in production today. I’m going to assume at least .NET
3.5, and with some minor alterations, all of the code samples provided in this chapter will
work in that environment. Even if you work in a more recent version of .NET, but are
unfamiliar with Functional Programming, I still recommend reading this chapter, as it should
give you a decent starting point in programming with the Functional Paradigm.
Those of you familiar already with Functional code, and just want to see what’s available in
the latest versions of .NET, it might be best to skip ahead to the next chapter.
Getting Started
Functional Programming is easy, really it is! Despite what many people think, it’s easier to
learn than Object Orientated progrmanning. There are fewer concepts to learn, and actually
less to get your head around.
If you don’t believe me, try explaining Polymorphism to a non-technical member of your
family! Those of us that are comfortable with Object Orientation have often been doing it so
long that we’ve forgotten how hard it may have been to get our heads around it at the
beginning.
Functional programming isn’t hard to understand at all, just different. I’ve spoken to plenty of
students coming out of university that embrace it with enthusiasm. So, if they can manage
it…
The myth does seem to persist though, that to get into Functional Programming, there’s a
whole load of stuff that needs learning first. What if I told you though, that if you’ve been
doing C# for any length of time, you’ve already most likely been writing Functional code for
a while? Let me show you what I mean…
Your First Functional Code
Before we start with some functional code, let’s look at a bit of non- functional. A style you
most likely learned somewhere very near the beginning of your C# career.
A Non-Functional Film Query
In my quick, made-up example, I’m getting a list of all films from my imaginary data store
and creating a new list, copied from the first, but only those items in the Action genre1
public IEnumerable<Film> GetFilmsByGenre(string genre)
{
var allFilms = GetAllFilms();
var chosenFilms = new List<Film>();
foreach (var f in allFilms)
{
if (f.Genre == genre)
{
chosenFilms.Add((f));
}
}
return chosenFilms;
}
var actionFilms = GetFilmsByGenre("Action");
What’s wrong with this code? At the very least, it’s not very elegant. That’s a lot we’ve
written to do something fairly simple.
We’ve also instantiated a new object that’s going to stay in scope for as long as this function
is running. If there’s nothing more to the whole function than this, then there’s not much to
worry about. But, what if this were just a short excerpt from a very long function? In that
instance, the allFilms and actionFilms variables would both remain in scope, and thus in
memory all that time, even if they aren’t in use.
Not only are they both in scope, but we’re holding two copies of all action films, one in the
original allFilms variable, the other in this new actionFilms variable. That’s more memory
than we strictly need to hold.
We’re also forcing the order of operations. We’ve specified when to loop, when to add, etc.
Both where and when each step should be carried out. If
there were any intermediate steps in the data transformations to be carried out, we’d be
specifying them too, and holding them in yet more potentially long-life variables.
What if there were a more optimal order of operations than the one we’ve decided on? What
if a later bit of code actually meant that we don’t end up returning the contents of
actionFilms? We’d have done the work unnecessarily.
This is the eternal problem of procedural code. Everything has to be spelled out. One of our
major aims with Functional Programming is to move away from all that. Stop being so
specific about every little thing. Relax a little, and embrace declaritive code.
A Functional Film Query
So, what would that code sample above look like written in a Functional style? I’d hope
many of you might already guess at how you would re-write it.
public IEnumerable<Film> GetFilmsByGenre(IEnumerable<Film> source, string genre) =>
source.Where(x => x.Genre == genre);
var allFilms = GetAllFilms();
var actionFilms = GetFilmsByGenre(allFilms, "Action");
If anyone at this point is saying “isn’t that just LINQ?”, then yes. Yes, it is. I’ll let you all in
on a little secret - LINQ follows the Functional paradigm.
Just quickly, for anyone that’s not yet familiar with the awesomeness of LINQ. It’s a library
that’s been part of C# since the early days, and provides a rich set of functions for filtering,
altering and extending arrays of data.
Functions like Select, Where and All are from LINQ and commonly used around the world.
Think back for a moment to the list of features of Functional Programming, and see how
many LINQ implements…
Higher-order Functions - The lambda expressions passed to LINQ functions are all
functions, being passed in as parameter variables.
Immutability - LINQ doesn’t change the source array, it returns a new
Enumerable based on the old one.
Expressions instead of Statements - We’ve eliminated the use of a
ForEach and an If
Referential Transparency - The Lambda Expression I’ve written here does actually conform
to Referential Transparency (I.e. “no side effects”), though there’s nothing enforcing that. I
could easily have referenced a string variable outside the Lambda. By requiring that the
source data be passed in as a parameter, I’m also making it easier to test without requiring the
creation & setup of a Mock of some kind to represent the data store connection. Everything
the function needs is provided by its own parameters.
The iteration could well be done by recursion too, for all I know, but I have no idea what the
source code of the Where function looks like. In the absence of evidence to the contrary, I’m
just going to go on believing that it does.
This tiny little one-line code sample is a perfect example of the Functional approach in many
ways. We’re passing around functions to perform operations against a list of data, creating a
new array based on the old one.
What we’ve ended up with by following the Functional paradigm is something more concise,
easier to read and therefore far easier to maintain.
Results-Orientated Programming
A common feature of Functional code is that it focuses much more heavily on the end result,
rather than on the process of getting there. An entirely Procedural method of building a
complex object would be to instantiate it empty at the beginning of the code block, then fill in
each property as we go along.
Something like this:
var sourceData = GetSourceData();
var obj = new ComplexCustomObject();
obj.PropertyA = sourceData.Something + sourceData.SomethingElse;
obj.PropertyB = sourceData.Ping * sourceData.Pong;
if(sourceData.AlternateTuesday)
{
obj.PropertyC = sourceData.CaptainKirk; obj.PropertyD = sourceData.MrSpock;
}
else
{
obj.PropertyC = sourceData.CaptainPicard; obj.PropertyD = sourceData.NumberOne;
}
return obj;
The problem with this approach is that it’s very open to abuse. This silly little imaginary
codeblock I’ve created here is short and easy to maintain. What often happens with
production code however, is that the code can end up becoming incredibly long, with
multiple data sources that all have to be pre- processed, joined, re-processed, etc. You can
end up with long blocks of If- statements nested in If-statements, to the point that the code
starts resembling the shape of a Family Tree.
For each nested If-statement, the complexity effectively doubles. This is especially true if
there are multiple return statements scattered around the codebase. The risk increases of
inadvertently ending up with a Null or some other unexpected value if the increasingtly
complex codebase isn’t thought through in detail. Functional Programming discourages
structures like this, and isn’t prone to this level of complexity, or of the potential unexpected
consequences.
In our code sample above, we have PropertyC and PropertyD defined in 2 different places.
It’s not too hard to work with here, but I’ve seen examples where the same property is
defined in around half a dozen places across multiple classes and sub-classes2.
I don’t know whether you’ve ever had to work with code like this? It’s happened to me an
awful lot.
These sorts of large, unweildy codebases only ever get harder to work with over time. With
each addition, the actual speed at which the developers can do the work goes down, and the
business can end up getting frustrated because they don’t understand why their “simple”
update is taking so long.
Functional code should ideally be written into small, concise blocks, focusing entirely on the
end product. The expressions it prefers are modelled on mathematical working, so you really
want to write it like small formulas, each precisely defining a value and all of the variables
that make it up. There shouldn’t be any hunting up and down the codebase to work out where
a value comes from.
Something like this:
function ComplexCustomObject MakeObject(SourceData source)
=>
new ComplexCustomObject
{
PropertyA = source.Something + source.SomethingElse, PropertyB = source.Ping *
source.Pong,
PropertyC = source.AlternateTuesday
? source.CaptainKirk
: source.CaptainPicard, PropertyD = source.AlternateTuesday
? source.MrSpock,
: source.NumberOne
};
I know I’m now repeating the AlternateTuesday flag, but it means that all of the variables
that determine a returned property are defined in a single place. It makes it much simpler to
work with in the future.
In the event that a property is so complicated that it will either need multiple
lines of code, or a series of Linq operations that takes up a lot of space, then I’d create a
break-out function to contain that complex logic. I’d still have my central, result-based return
at the heart of it all, though.
A few words about Enumerables
I sometimes think Enumerables are one of the most under-used and least understood features
of C#. An Enumerable is the most abstract representation of a list of data - so abstract that it
doesn’t contain any data itself, it’s actually just a description held in memory of how to go
about getting the data. An Enumerable doesn’t even know how many items there are
available until it iterates through everything - all it knows is where the current item is, and
how to iterate to the next.
This is called Lazy Evaluation or deferred Execution. Being lazy is a good thing in
development. Don’t let anyone tell you otherwise3.
In fact, you can even write your own entire customised behaviour for an Enumerable if you
wanted. Under the surface, there’s an object called an Enumerator. Interacting with that can
be used to either get the current item, or iterate on to the next. You can’t use it to determine
the length of the list, and the iteration only works in a single direction.
Have a look at this code sample:
var input = new[]
{
75,
22,
36
};
var output = input.Select(x => DoSomethingOne(x))
.Select(x =>
DoSomethingTwo(x)) DoSomethingThree(x));
.Select(x =>
What do you think the order of operations is? You might think that the runtime would take
the original input array, apply DoSomethingOne to all 3 elements to create a second array,
then again with all three elements into DoSomethingTwo, and so on.
If I were to add some basic logging into each of those functions, you’d actually get back
something like this:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingTwo(75)
18/08/1982 11:24:02 - DoSomethingThree(75)
18/08/1982 11:24:03 - DoSomethingOne(22)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingThree(22)
18/08/1982 11:24:06 - DoSomethingOne(36)
18/08/1982 11:24:07 - DoSomethingTwo(36)
18/08/1982 11:24:08 - DoSomethingThree(36)
It’s almost the exact same as you might get if you were running this through a For/ForEach
loop, but we’ve effectively handed over control of the order of operations to the runtime.
We’re not concerned with the nitty-gritty of temporary holding variables, what goes where
and when. Instead we’re just describing the operations we want, and expecting a single
answer back at the end.
It might not always look exactly like that, it depends on what the code that calls it looks like.
But the intent always remains, that Enumerables only actually produce their data at the
precise moment it’s needed. It doesn’t matter where they’re defined, it’s when they’re used
that makes a difference.
Using Enumerables instead of solid arrays, we’ve actually managed to implement some of the
behaviors we need to write Declarative code.
Incredibly, the log file I wrote above would still look the same if I were to re- write the code
like this:
var input = new[]
{
1,
2,
3
};
var temp1 = input.Select(x => DoSomethingOne(x));
var temp2 = input.Select(x => DoSomethingTwo(x));
var finalAnswer = input.Select(x => DoSomethingThree(x));
temp1, temp2 and finalAnswer are all Enumerables, and none of them will contain any data
until iterated.
Here’s an experiment for you to try. Write some code like this sample. Don’t copy it exactly,
maybe something simpler like a series of selects amending an integer value somehow. Put a
break point in and move the operation pointer on until final answer has been passed, then
hover over finalAnswer in Visual Studio. What you’ll most likely find is that it can’t display
any data to you, even though the line has been passed. That’s beause it hasn’t actually
performed any of the operations yet.
Things would change if I did something like this:
1 var input = new[]
2 {
3 1,
4 2,
5 3
6 };
7
8 var temp1 = input.Select(x => DoSomethingOne(x)).ToArray();
9 var temp2 = input.Select(x => DoSomethingTwo(x)).ToArray();
10 var finalAnswer = input.Select(x => DoSomethingThree(x)).ToArray();
Because I’m specifically now calling ToArray() to force an enumeration of each intermediate
step, then we really will call DoSomethingOne for each item in input before moving onto the
next stop.
The log file would look something like this now:
18/08/1982 11:24:00 - DoSomethingOne(75)
18/08/1982 11:24:01 - DoSomethingOne(22)
18/08/1982 11:24:02 - DoSomethingOne(36)
18/08/1982 11:24:03 - DoSomethingTwo(75)
18/08/1982 11:24:04 - DoSomethingTwo(22)
18/08/1982 11:24:05 - DoSomethingTwo(36)
18/08/1982 11:24:06 - DoSomethingThree(75)
18/08/1982 11:24:07 - DoSomethingThree(22)
18/08/1982 11:24:08 - DoSomethingThree(36)
For this reason, I nearly always advocate for waiting as long as possible before using
ToArray() or ToList() 4, because this way we can leave the operations unperformed for as
long as possible. And potentially even never performed if later logic prevents the
enumeration from occurring at all.
There are some exceptions. Either for performance, or for avoiding multiple iterations. While
the Enumerable remains un-enumerated it doesn’t have any data, but the operation itself
remains in memory. If you pile too many of them on top of each other - especially if you start
performing recursive operations, then you might find that you fill up far too much memory
and performance takes a hit, and possibly even end up with a stack overflow.
Prefer Expressions to Statements
In the rest of this chapter, I’m going to give more examples of how Linq can be used more
effectively to avoid the need to use statements like If, Where, For, etc. or to mutate state (i.e.
change the value of a variable).
There will be cases that aren’t possible, or aren’t ideal. But, that’s what the rest of this book
is for.
The Humble Select
If you’re reading this book, you’re most likely aware of Select statements, and how to use
them. There are a few features though, that most people I speak to don’t seem to be aware of,
and they’re all things that can be used to make our code a little more functional.
The first thing was something I’ve already shown in the previous section - you can chain
them. Either as a series of Select function calls - literally one after the other, or in a single
code line; or else you can store the results of each Select in a different local variable.
Functionally these two approaches are identical. It doesn’t even matter if you call ToArray
after each one. So long as you don’t modify any resulting arrays or the object contained
within them, you’re following the Functional paradigm.
The important thing is to get away from is the Imperative practice of defining a List, looping
through the source objects with a ForEach and then adding each new item to the List. This is
long-winded, harder to read, and honestly quite tedious. Why do things the hard way? Just
use a nice, simple Select statement.
Passing working values via tuples
Tuples were introduced in C#7. Nuget packages do exist to allow some of the older versions
of C# to use them too. They’re basically a way to throw together a quick-and-dirty collection
of properties, without having to create and maintain a class.
If you’ve got a few properties you want to hold onto for a minute in one place, then dispose
of immediately, Tuples are great for that.
If you have multiple objects you want to pass between Selects, or multiple items you want to
pass in or out of one, then you can use a Tuple.
