WTF is FP? For the Mildly Curious to the Mostly Skeptical

Ever caught yourself spending an unreasonable amount of time trying to name something¹, or pondering over architectural decisions² that you couldn’t care less about, out of fear that some may come back to haunt you?

As mentioned in the introdution to this series, most devs just care about writing simple code that works, but it’s deceptively easy to stray from that goal.

As a developer you’ve been creating and using functions your whole career, but if functions aren’t exclusive to Functional Programming, what makes it “functional” and — more importantly — how could things that you’re already using possibly solve problems you’re still facing?

Bonus question: when you look at Vladik’s picture below, do you see a fridge?

What do you see in the picture? A piece of cardboard? Some junk? No! — It’s a model!

Thread on models and bounded contexts 1/9#DDDesign #BoundedContext pic.twitter.com/URvUGh6Ho7

— Vladik Khononov (@vladikk) December 7, 2020

Bear with me 🙏

Programming is mostly modeling real world problems. As the statistician George Box once said:

All models are wrong but some are useful

If programming is modelling, and all models are wrong, you can think of programming as devising the simplest most useful model to solve a problem. Simplicity and usefulness are the goals, not accuracy.

The real world is seemingly made of objects, so one can understand the initial appeal of Object Oriented Programming.

But designing models has largely transitioned away from describing stuff to composing with simpler abstractions that:

• only make sense in very limited contexts
• have little-to-no resemblance to the original things they represent
• still get the job done

If we’re no longer describing stuff, it may be time to revisit the appeal of a programming paradigm that’s clearly meant to describe it.

A surprisingly simple distinction

It’s fair to say that while OOP focuses on what is, FP is about what happens:

• A function is nothing but the definition of what happens to its input
• FP code is nothing but a composition of functions, or an arrangement of happenings

This distinction significantly mitigates the two problems from the intro.

What something is depends on the context. Take MVC for instance, which you may know by MVVM or MVP, it’s about representing something with different objects specialized for the context in which they’re being used.

But what something is also changes over time, which is why in a lasting evolving business you shouldn’t be too eager to spend time and energy describing stuff that’s going to change anyway.

Build on more stable ground

Interestingly, while what something is varies a lot, what happens doesn’t, or not nearly as much anyway. Once you create a function, let’s call it add, assuming it’s been tested and performance is good, it will likely never have to change.

Sure, your business will evolve, you may have created it to add cows, then later reused it to add bitcoins. And yes, one day you may get rid of it altogether, a routine procedure with proper self-contained functions, but a high-risk operation with traditional intertwined object models.

It’s just a simple fact of life, over time everything changes, and the secret weapon of devs that embrace change is focusing on verbs instead of subjects. Define what happens instead of naming, classifying, and categorizing all the things.

We’re ready for a definition

Now that we’ve established that programming is basically modelling, we can safely guess what Functional Programming is: modelling real world problems and solutions with functions.

You still use all the familiar things like strings, ints, floats, collections, and yes, some like myself even use objects and classes, but the occurrence of these is relegated to function signatures, and definitely not part of a grand design some poor soul had to contrive into existence before writing any real code.

Remember, a model isn’t trying to accurately recreate the real world, it’s trying to efficiently solve for a problem. Solving for a problem isn’t “stuff”, it’s “doing stuff”, it’s providing the appropriate output for a given input. It’s a function. It always has been.

The real world case for FP

Even with all this talk about models, it’s possible some of you still find comfort in their programming paradigm being object oriented because the real world is seemingly made of objects.

I’d like to leave you with some 18th-century wisdom from our friend Antoine Lavoisier, to be read out loud with your best french accent:

Nothing is lost, nothing is created, everything is transformed

The law of conservation of mass describes literally everything as the product of a transformation, so even nothing here convinced you and all you want is something that feels like “the real world”, then you should favor a paradigm made of transformations.

A transformation, young software alchemist, is just a fanciful name for the all-mighty function, the very topic of the next article!

The journey continues ⛵

This is the first time I write for non-FP programmers, if you exist and are interested in the next article in the series, please let me know by retweeting, liking, or replying to this twitter thread, and until next time, safe journey!