Okay, thanks for the answer.

Here, in the whole series, I describe the approach of simple functional programming. In this approach, early returns are to be avoided. We have other ways to improve readability, without nesting, and we consider early returns more like a potential risk for introducing bugs later on.

After all, an early return forces us to code in the imperative style:

1. Check the condition and if it's not fulfilled, return early with a result done in a different way or throw an exception.

2. Do what the function was supposed to do.

We need to do it in two steps, there's no other way. And it means that in the step 2 we need to remember the context - that there was the step 1 before. The domain of the step 2 becomes only a subset of the domain of both steps 1 & 2 - some cases are now filtered out. If we forget about it, we may introduce a bug.

In the FP approach, this is much better described as a call to another function with a more limited domain. So what we get instead of an early return is: "Check the condition and if it's fulfilled then call this function which accepts only valid input, otherwise make the result in a different way or produce an error". We can return the valid result wrapped in `Right` and the error wrapped in `Left`. Types helps us to distinguish what is what. We don't have to remember about the context anymore.

Of course there's always more than one way to do something in programming and I can imagine situations when an early return might be useful if you stick to other practices that minimize the risks. (In fact, I wrote something about it recently: https://medium.com/nerd-for-tech/many-happy-early-returns-2e0d71bfa691 *tadaah, shameless autopromotion :) ). But all this - what I describe in this series of posts and videos - is what I came up with in my work and what I believe is the best. So that's why I write about it.