The purest coding style, where bugs are near impossible

If you've heard the words functional programming, you might think it has something to do with functions, and you'd be right.

Functional programming is a paradigm a lot of us use all the time, and maybe don't even know it.

It's about the way we structure our code and the immutability of a pure, yet somewhat impractical world.

It's about math and equations and side effects, and it even comes with some delicious curry.

So, let's take a look at what may make functional different from the way you've been programming so far.

What exactly is a programming paradigm, then?

Well, to answer that, I give you a tree.

It's a special tree, though.

One that we can use to show how programming languages branch into different families, just like spoken languages.

Looking at the two biggest branches, we have imperative, or the paradigm of giving explicit instructions.

Basically, the how.

And declarative, or the paradigm of describing our goal.

Basically, the what.

As we go down each branch, we go from more generic programming paradigms to more specific ones.

Each programming language you will use follows a recipe of one or more available programming paradigms.

And in reality, a lot more paradigms exist than the two branches I've just mentioned.

About halfway down the declarative branch, we have the functional paradigm,

which outlines the common concepts or styles behind what makes functional programming unique

when compared with other common paradigms such as object-oriented or procedural.

At the core of the functional paradigm, we have functions, obviously.

And these functions need to be usable in a fairly unrestricted way,

meaning we can pass them to other functions and return them from other functions,

as well as hold references to them for later use.

We also need to be able to create closures, which are functions that can access and remember the scope around them.

In a typical function stack, the scope of a function is forgotten when leaving it.

But when a closure is created, that scope stays in memory for as long as the closure still exists.

This means that we can return a closure from a parent function

and still have access to all the arguments and data that the parent function also had access to,

even if we call the closure from a completely different scope later on.

Hey, it's me from the future.

I realized that closures might need a bit more explanation, so here's some code to help.

We can see that closures are just simple anonymous functions that we define inside of other functions.

What makes closures special, though, is the fact that they can always access the data of the parent function that created them,

even if we return them and that parent function goes away.

Because they can always access their parent scope like this,

we can go crazy and put closures inside of closures to access all the way back to the function that originally created the first one.

And we'll use this concept later on in the video.

Their ability to store data in this way means that closures are sometimes described using this quote that I think might help the OO programmers.

"A closure is a poor man's object...

...and an object is a poor man's closure."

Anyway, let's get back to it.

How can we use these features in a functional way?

We can start by creating some higher order functions,

which are functions that work with other functions to basically perform an action.

Think filter(), sort(), map(), and so on.

These help us to create reusable and isolated modules

that we can compose together to write our code more declaratively.

Next we have immutability, where we aim to avoid something called side effects.

Side effects happen when we allow unpredictable state from outside the scope of a function to affect it in some way,

or when we allow a function to make changes outside of its scope.

In getting rid of potential side effects, our functions become pure,

in that if the same data goes into a function, we can always guarantee the same result coming out, without affecting anything else.

This is typically enforced by removing the variability of variables.

Lastly, we can use closures as a way to encapsulate data and state.

There's an important concept in functional programming called currying.

I told you there'd be curry.

Currying brings up multiple arguments of a function into their own function calls that we then chain together.

It achieves this using the scope memory ability of closures,

where each argument will stay in memory until the chain completes, and we get our result.

In a similar way, we can use closures to create something resembling an object.

The first function in the chain acts as a kind of object constructor,

and would be where we define most of our internal data.

This data is privately scoped to the constructor function, and therefore encapsulated by it.

We can then return a closure to provide external access to this private data.

This can be used for simple tasks, such as pre-computing and storing the result of expensive operations,

something we call memoization.

Or we can go as far as returning multiple named closures to access and manipulate the internal data in more complex ways,

further solidifying it in its object-like behaviors.

Anyway, these are just techniques that we use in the functional paradigm.

We haven't yet really inspected the core values of what it means to be purely functional.

We enter a world where everything is declarative, deterministic, and ideally unchanging, pretty much forever.

While that may not sound very useful on the surface, it has its roots in the mathematical world, and there it actually makes a lot of sense.

In the purely functional paradigm, we work primarily with types and expressions, where the following rules apply:

Code is generally evaluated rather than executed, which gives us some interesting new optimization abilities,

such as lazy evaluation and automatic parallelization.

Immutability is enforced everywhere, meaning that when we want to make changes to our data,

we do so by computing a new constant based off of an existing constant.

And to keep functions pure, the mere thought of a side effect is punishable by the most horrific torture imaginable.

Having to learn...

MONADS!

Now, this (purely functional) world is beautiful, but it's really not for the faint of heart.

And so most of us mortal programmers just take the smallest fruits hanging from the purely functional branch, and we try to use them as best we can.

With all these differences in mind, why would we use the functional paradigm?

Well, there's actually many benefits to it.

The immutability of the functional paradigm forces us to think more strictly about how we pass data around,

helping to ensure that changes don't happen unexpectedly.

It also guides us in forming readable code that's highly modular and therefore maintainable.

It does come at the cost of potentially being a bit harder to optimize though, depending on where in the branch you're using functional,

and can be a bit of a challenge to transition to a more declarative approach if you're already used to imperative styles of programming.

Anyway, whether you consider yourself a functional programmer, object-oriented programmer, or just like the basic simplicity of procedural code,

always keep an open mind and never be scared to learn more.

Even if you don't end up using functional, learning something new is never a waste of time.

I'd like to finish by thanking the sponsor of this video, RunMe.

They're offering a completely free and open source extension for VS Code that turns your basic markdown files into fully interactive notebooks

where you can run terminal commands or code snippets, then view the results without ever leaving the documentation you're in.

Now this is really great for Development and DevOps, where you can test out snippets of code or document and share workflows with the rest of the team.

What's more, all of the core functionality of RUNME is actually powered by a separate executable,

which you can interact with in all of the same ways as you can in VS Code.

What this means is you get some power and flexibility.

You can use RUNME however you want, whether it's your favorite terminal, third-party integration, or in an automation such as your build pipeline.

Anyway, the team are really nice people, and they're looking for your input to make this a really great product.

So go to RUNME.dev, check it out, and visit their Discord to get involved.

Thank you for watching, and I'm so sorry it took so long to make this video.

I really wanted it to be right, not rushed, so I ended up rewriting it a lot before finding a satisfactory way to tell the functional story.

Honestly, I've really loved learning more about the functional paradigm, especially the pure side.

It's complex, but fascinating at the same time, and I'd highly recommend diving into it yourself, no matter your background.

I hope you enjoyed it, and as always, I'll see you next time.