Hello, everyone. It's great to be here. Imagine a world where your code is perfectly understandable.
Imagine a world where concurrency is a piece of cake. Imagine a world where testing is a breeze.
Well, I don't know if such a world exists, but we can get close. Let's go on
a journey to the world of functional programming. Functional programming is one of the ways
of writing software, and, like object-orientated and procedural, it has its own rules and patterns.
No matter what programming approach and technologies you're using, learning functional programming
is a great way to grow as an engineer. On our journey, we are going to have some fun,
and we will bring back treasures that will help our teams become better engineers in
everyday work. When I first went there, it was quite weird. It's my first day at the
university, and unsuspecting, I go to a programming class. And the rules? No mutable variables.
No loops. I'm, like, how can I even build anything this way? It turns out they put me
in a functional programming class. So, it was quite weird in the beginning, but once
I got the idea, it was - it became a lot of fun, and since then, I've done functional
programming a lot, and it has changed the way I think about software. So I've brought
a map for us. As you can see, we have three places to visit, and three treasures to discover
today. Are you ready? Okay, great, let's go. We started by landing on the immutability
island. The rule of the core of functional programming is that there is no mutable state,
and that functions have no side effects. For example, imagine you want to insert a value
into a dictionary. In the imperative way, you would have an update function that replaces
that value. Now, in the functional way, we cannot modify the dictionary, so, instead,
our update function returns a new dictionary that contains this value. It leaves the original
dictionary intact. Using only immutable data makes you design your programmes differently.
You kind of have data flow through the application only in one direction. Also, in the functional
way, function has no side effects. For a given argument, it always returns the same result.
It does not talk to the outside world; it does not rely on hidden inputs; it does not
do anything more than it seems to. So, what does life look like on the immutability island?
Easier. First of all, code is easier to reason about. You just know that function cannot
do certain things, and the flow of data is simplified, and this means less details to
hold in our head. Code is easier to test because, when you have side effects, to test a method,
you need to simulate and verify all the side effects. And, when they're gone, it is just
a matter of verifying that if input is this, then the output is that. Code is easier to
parallelise since there is no shared mutable state, there can be no race conditions, so
we don't have to worry about them, all the communication is explicit. So, what treasures
can we take with us back home from the immutability island? Well, we become to appreciate the
benefits of immutability, and lack of side effects. Even if you write small parts of
your programmes like that, you can already get and feel the benefits, just as React applied
immutability to simplify the most complex ability of building front ends, we can bring
immutability and lack of side effects to crucial parts of our programmes. All right, moving
on, second place, we come to the declarative desert. You see, the nature of functional
programming is declarative. We define what to accomplish instead of how to accomplish
it exactly. We build solution s by decomposing the whole problem into smaller sub problems,
instead of defining steps and recipes to change our world in a certain way. So, what is it
like on the declarative desert? Code becomes easier to understand. You don't need to replay
all the steps written in code in your head to understand what the code does. Also, the
control flow is not hard-coded, mixed with the logic. It is the compiler that has the
flow. Also, you have to decompose problems really well, and this gives great reusability
and composability of components. So, what treasures can we take with us back home from
the declarative desert? Well, designing around what and hiding the implementation details
of how something is done is a good practice in general. And functional programming is
a fantastic practice of that. We learn to decompose better, we become used to expressing
the desired outcome of our code. Our solutions become more usable, more extendible, and easier
to understand. Okay, so, are you ready for the third place to visit?
AUDIENCE: Yes! MAREK: It's the Perspective Peak. Writing
programmes in a functional way is very much different. Because of that, it gives you a
new way of thinking about programming. What is it like on the perspective peak? There
are a number of things that you just do differently. For example, functioning are first-class citizens,
and you often parse them as a argument to another function or retain them as a result.
Also, you generally have different ways of doing simple things. You don't have loops.
Instead, you use functions like map and fold, and also there are a number of more advanced
concepts that are very powerful, very interesting, and very deep, and you don't need them to
start and succeed, but once you're ready to learn them, they can give you even a broader
perspective. So what treasures can we take with us from the perspective peak? Well, it's
like travelling to different countries or continents, or like travelling to the countryside
- you don't need to bring back anything specific with you to feel that it was worth it. Every
now and then, I like to travel to a village my grandparents live in, and I meet the amazing
people with a completely different world and priorities, and I come back with a refreshed
perspective of distance, and with new ideas how to approach my day-to-day problems. There
are countless examples of this functional perspective inspiring projects like React,
we already mentioned, or distributed processing frameworks, map reduce, and Spark. We often
invest time into learning new frameworks and technologies, and that's great, but, at some
point, it's just that frameworks come and go. They are replaced by new ones, sometimes
that are better, and learning a new way of thinking will never get outdated. All right,
so this was the third place on our map. And on our way back home, there is one more question
to answer: how to encourage developers on our teams to explore functional programming.
Well, first of all, most developers love learning new exciting things, so just share the idea
and give them space to try it out. Second, talk about points that are most relevant to
their current level of experience to the problems they're now facing, like is it for them safety,
is it concurrency, is it readability, is it testing? Third, set the expectations right
so they don't get discouraged. This is not the same as learning just another programming
language. They might feel like beginners for a while before things click. Finally, share
good learning resources. I have posted this presentation on Twitter, so you don't need
to read this now. You can look this up later. Here are a couple I can recommend. All right,
welcome back to London. Let's see what we've brought back from our journey. From the immutability,
we've brought back the immutability and lack of side effects. From the declarative desert,
designing what, not how. From the perspective peak, we've brought a new way of thinking
about programming. If you want your teams to discover these treasures, take them on
a journey to the world of functional programming. Thank you! [Applause].