What Making a Cup Of Tea Taught me about Functional Programming.

Learning Actors
Share :

Like most people, I have a hard time understanding Functional Programming. Following the same path as many others. I spent hours scratching my head watching youtube, reading blogs and attending talks. All in aid off a finding better understanding.

But, In a surprise twist. The thing that joined all the confusing dots together was not an oracle of our craft, Nor was it hours of study. Instead it was something that, as a Mancunian¹, I do a lot.

Make Tea

Before you think I’ve gone nuts, let me ask you a question.

How do you make a cup of tea?

Well making a cup of tea has a few steps. To start with, Lets put some water in a kettle. On a flow diagram you can represent this step like this:

Once the water is in the kettle, we can put the kettle on boil. Let’s represent that like this:

What’s the most important part of this diagram? The little arrow between these steps. This arrow represents sequence.

This sequence is the product of a side affect putting water in my kettle has led there to be well, water in my kettle. Only because of this is is the boil step able to run. Step 2 is dependent on step 1.

Let’s leave that aside and continue making our tea. I now need boiling water so I guess I should check if my water is boiled.

If the kettle is boiled I want to move on by adding the water to the mug. You could represent that like this:

What we’ve got here is called selection. There are two roads I can go down. If the condition true, go down one path. Otherwise go down the other.

Let’s consider the other path. If the water is not boiled I wan’t to wait for a few seconds and then try again and again and again. This is called iteration. I want to do something again and again until a condition is met.

Now I expect that you actually know how to make tea, so I’m going to Jump to the end of my Tea diagram. But have a good look at it. Let it sink in.

Most of us have spent our whole careers writing code that, once we remove all the abstractions and syntactic sugar, look like this tea making flow chart. In fact here it is in Java:

Mug makeTea(sugarWanted, milkWanted) {
  Kettle kettle = new Kettle();
  kettle.add(water);
  kettle.boil();
  
  while(!kettle.hasBoiled()) {
    sleep(5);
  }
  
  Mug Mug = new Mug();

  Mug.add(new Teabag())
  
  if(sugarWanted) { 
    Mug.add(new Sugar());
  } 
  
  sleep(300);
  
  if(milkWanted) { 
    Mug.add(new milk());
  } 
  
  return Mug;
}

This is called imperative programming. imperative programs compose of a sequence of events the flow of the program can branch based on a selection mechanism. Jumping back to a previous point in the algorithm allows us to iterate.

Now I’m going to tell you a secret. There is another way. What if we described a function as a flow of data.

Photo by Manuel Cosentino on Unsplash

So what do we need to make Tea. On a recipe, The ingredients list would Include:

  • Teabag
  • Water
  • Milk (optional)
  • Sugar (optional)

So let’s try an think what needs to change. Well Firstly they all need to end up in the mug.

In a C-style Language it might look like this.

Mug makeTea(teabag, water, milk, sugar) { 
  mug.add(teabag, water, milk, sugar);
  return mug
}

would that work? No it would be cold!!

So I Wan’t to boil the water before adding to the mug.

Mug makeTea(teabag, water, milk, sugar) { 
  mug.add(teabag, boil(water), milk, sugar);
  return mug
}

And that’s it.

Scroll up, Look at the code for our imperative solution. Now look at our new solution.

Imagine if you didn’t know what these functions we’re for. for example if you had opened a file in an area of your codebase that you weren’t familiar with. Which would you recognise to be a Tea making algorithm quicker?

What I’ve just described is called a Declarative style. A declarative style is about saying what you want not how you want to do it.

Declarative has more use cases than describing programs as a flow of data like in this example. A simple example would be a HTML tag is a perfect example of describing what rather than how you want to do it.

<p> I want a paragraph with this text </p>

But as this is a blog on Functional Programming, let’s keep out minds on the Flow of data use case.

So is this functional Programming?

No, But this declarative style is a key tenet of Functional Programming. More so, My biggest obstacle to understanding Functional Programming was that was that I was conditioned to think in an imperative style – The first style described in this blog. If you think in an imperative style many Functional Programming concepts they made no sense. This was because they are often hard or hacky to write when combined with imperative code. When you begin to think in terms of the flow of data. Like in the second approach. subsequent concepts become much easier to understand and implement in your code.

So this blog has taught you the first thing you need to know on your Functional Programming Journey.

Source: medium

Share :