Why Functional Programming?

In this post, I would like to share why I think the functional paradigm is such a big deal, and why it is worthwhile to learn about it, no matter which technology you are using.

Functional Programming Roots

Functional Programming (FP) is deeply rooted in maths, and is intimidating because of that. But I think we underestimate the value of a mathematical approach of software: it allows to express complex problems with a succession of simple statements. When we translate this to IT, the point is to compose complexity to keep software systems predictable, no matter how big they are.

How mathematics works

Mathematics always follow the same pattern. They define something in a general way, like a polygon: “a polygon is a plane figure that is bounded by a finite chain of straight line segments closing in a loop to form a closed polygonal chain”. Then by applying specific laws, they are able to define more specific things: “A triangle is a polygon with three edges and three vertices”. And by adding more laws, we obtain even more specific things, like an equilateral triangle “An equilateral triangle has all sides the same length”. As you will see, FP design patterns can be explained in the same way: we will use something general, and because we will add some laws, it will define a more specific concept. Note that “A monad is just a monoid in the category of endofunctors” follows this pattern as well. It seems complicated because it uses other concepts we’re not familiar with.

Don’t be scared to learn the symbols

Maths are often intimidating due to complex words and abstract symbols. Learning them is a first step to demystify it. Here are some symbols often used to explain FP concepts:

The mathematical notation y=f(x) means for x, the relation f will produce the output y. f: a->b means for an input a, the relation f will produce an output b. We usually use this notation in FP. Of course we need to define the set for a  and b (integers, positive integers, real numbers, string…). The set of a is called the domain of f, and the set of b is called the codomain of f.

g°f means the composition of g and f, in other word the application of f,then g.

f ≡ g means that f is equivalent to g.

Software predictability

In a pure FP program, f: a->b is always true. Functions are pure, which means they will always produce the same output for the same input, no matter when the function is called. In our industry, because states can mutate over time, we build software where it’s false. If f has side effects, or if anyone can mutate a or b, we can no longer predict the output of f, because it is context dependent. It adds a lot of complexity in our code. Building a program by composing pure function can remove this complexity.

Why Function Composition?

Functional programming is all about function composition. If I have 2 function f:a->b and g: b->c, I want the composition g°f : a->c. The composition of simple functions allows to build services. The composition of services can manage use cases. And a composition of uses cases is an application.

Wrap up

Don’t be scared by mathematical symbols, and remember that if we compose pure functions by respecting some mathematical laws, we’ll be able to build a predictable complex software. It is certainly something that has some interest, isn’t it?

The post where you don’t learn what’s a monad, but where you may want to learn more about it

Since a while I wander how to write another blog on the internet trying to explain what’s a monad. The problem is well known, as soon as you understand what a monad is, you lose the ability to explain it.
The good news is that I still don’t fully understand what’s a monad, so maybe I’m still able to explain it.
I don’t claim to be a mathematician, or Functional Programming (FP) expert. To be honest I am pretty bad in maths, and I use F# when I can, but I still work with C# most of the time.
Thus if you are an expert and see any errors in the FP related blog posts , please do me a favor and correct me 🙂


A combination of Failures

To explain monads, I started a first blog post, to explain the math theory and stay at a theoretical level. My draft was quickly 3 pages long, and unclear, even for me. How deep should I dig into the maths? Ok then, let’s try the practical approach.
I started a new blog post, only to focus on a practical example, to show how we can handle error with something close of the maybe monad. I tried to present my work in a local meetup, and to livecode the explanation. By the way it was a 10-minutes talk. No need to say it was also a failure, I hope the attendees learn some stuff, but they certainly still not understand what’s a monad.


What’s the point?

It slowly drives me crazy. I was thinking day and night about which metaphor I could use to explain monads. Something different from the railway metaphor from Scott Wlaschin if possible. I started two more blog posts, and was still unhappy with them.
Weeks were running, and I couldn’t explain monads in the simple way I was looking for.
I tried to figure out at which moment in my learning path I finally understood it. I also challenged the really reason to do that? Why should I care? Why a developer should know what’s a monad?

Why should we care?

Because monads are a basic building block in functional programming. I think this tweet  nailed it.
Semigroup, monoid, applicative and monad are building blocks, or design patterns inspired from mathematics. They allow to combine anything.
And because functional programming is all about function composition,  it is important to know these blocks as a functional programmer. But the concepts of FP are helpful for an Object Oriented (OO) developer in many aspects as well, as uncle Bob recently points out.


What’s a monad?

Something hard to understand without the maths roots. That’s why I will realease several articles to explain both technical and mathematical aspects, this way you can choose which part is relevant for you. From basic maths to concrete example, choose your path to monads understanding!

In defence of defence of Software Craftsmanship and Uncle Bob

I hope some water has gone under the bridge after the “Google memo gate” followed by the “Uncle Bob is a misogynist gate”, so let’s discuss it again. During a few days, I feel almost uncomfortable to read Twitter. I read many anger reactions, many accusations and a few smart comments. I’d like to share my feelings in this post, because I believe I’m not the only one to feel bad about this thread.

In defence of software craftsmanship

I’d like to thank Daniel Irvine to have written a good post to defend software craftsmanship. I won’t rephrase here what he already said, but I would like to testify as a software craftsman. I came to this community explicitly because I was not looking only for technical excellence. And I think it is the case for most crafts(wo)men I know. It is an open minded and friendly community.
I feel that even more due to recent events, because at every new attacks in Paris, London, Barcelona or Turku, I can think to crafts(wo)men living here, and I hope nothing bad has happened to them. If I care about them it’s because I know we share some values and principles. Not only the quest for technical excellence, but also a deep respect for people, a willing to improve the things around them and to share their passion. I feel connected to them.

The software craftsmanship community is by far the place where I’ve met the more activists. They talk a lot about ethics, politics, environment, and of course diversity. I can’t remember a single SoCraTes I attended where several of these topics were not discuss. And it is important to me, because I know I must improve about them. Of course, it is not perfect, it is often the same people who talk about these topics. But please don’t assume that other people don’t talk about that because they are not interested. They don’t talk about that because like me, they are often part of a favourited majority, and don’t feel legitimate to discuss such topics. I know it’s wrong, I don’t try to justify it, I just try to explain how I feel, and why I need to change.
As a software craftsman, I would like to testify that this community is certainly not a bunch of old white men who care about TDD. To be honest, this is the community where I see the most diversity, in terms of country, sex, religion, and skin colours. I agree it is still not enough. But it is unfair to say that this community only care about technical stuff.

In defence of Uncle Bob

But I think we missed a post to defend Uncle Bob as well. I’d like to thank him for the many good, talks, books and blog articles he has written. He was the one who enlights the passion in me with Clean Code.
Of course, he has done some bad stuff as well (but who doesn’t?), and I don’t agree with every word he says. For instance, I don’t believe working 70 hours per week is mandatory to be a good software engineer. And no need to say I don’t believe that you should not fire someone who has toxic ideas.
But his point was more subtle: “Don’t fire someone just because you disagree with him”. I think his example and context was bad, but it raises a fundamental question: how do we differentiate toxic ideas and ideas we disagree with?  It’s a fair question because if we don’t agree with toxic ideas, aren’t we tempted to label as “toxic” any idea we might not like? How do we react with people who label agility, scrum, XP or craftsmanship as toxic?

I don’t have the answers, but my point is that the community has overreacted. Yes, the example was poor, yes, the context was bad. But instead of asking for explanations (that he writes here), and discussing the core question (how do we differentiate toxic ideas and ideas we disagree with?), there was lots of anger and unrational discussions about since when and how much Bob is a misogynist, and if we should refuse him to speak in conferences. Aren’t we open-minded? Aren’t we here to help each other? Uncle Bob is a master of technical stuff, but he says that he needs to improve on the topic of diversity. Like me, and like many other average white men in the industry.
The solution is not to ignore him and label his speech as “toxic”. The solution is to discuss, argue and teach, because we are all smart software engineers who share values and principles, including the willing to improve, and not only technically.

As a software craftsman, I would like to testify that this community is very open minded, and that it can help people to improve, even Uncle Bob.