Part I of III
From Objects to Functions
A Step-by-Step Guide to Designing Applications in a Functional Way
You may have noticed I haven’t blogged lately (sorry to be away). During the last two years, I‘ve been working diligently on a book about functional programming in Kotlin. My book is now available in beta from The Pragmatic Bookshelf:
by Uberto Barbini
I started collecting material for the book after my talk about writing a CQRS application in functional style at KanDDDinsky conference in 2018. During the same period, I had the fortune to work with great teams on big back-end Kotlin projects moving them to a functional approach — and so the scope of my book grew.
What started as a vague idea quickly became hard work and prevented me from having time to write blog posts. The good news is that work on the book is nearly complete. For those who prefer to read it on paper, the hardcopy version will come sometime this summer.
Why a Book on Functional Programming?
So why write another book on functional programming? They are not exactly rare nowadays…
First, I don’t think there are many books about how to build a complete application from inception to fully functional. Most books focus on using a specific library or learning functional programming in the abstract with small examples. These are perfectly good goals for a book, but I wanted to tell a different story.
Secondly, I wanted to show that functional programming is really something that helps you to build software better and quicker — it’s not just for impressing your friends with fancy words. Functional programming requires a rewiring of your brain, but it brings real advantages in terms of productivity.
And finally, I wanted to show that you don’t need a specific language or library to adopt it. What you need is to understand the principles behind functional programming.
What Is Functional Programming?
Strictly speaking, functional programming consists in making all your functions referentially transparent; this means that each function only uses its input parameters to produce its output, without altering the state of the system in any way (which is explained much better in the book).
To see what this mean, let’s look at an example. The first language I studied was Basic on the Sinclair ZXSpectrum.
Now, I think everybody would agree that Basic is definitely not a functional language. Yet somehow, surprisingly, it allows us to write pure functions with the DEF FN keyword. So we can write a perfectly functional program with it:
20 DEF FN p(a,b)=a*b
30 DEF FN q(x)=FN p(x,x)
30 DEF FN t$(x)="The square of " + x + " is " + FN q(x)
40 LET res = FN t$(9)"The square of 9 is 81"
Now don’t get me wrong, there are a lot of limitations in using Basic as a functional language, but this code in itself is not less functional than the equivalent in Haskell or F#.
What Makes a Language Functional?
So what is a functional language, and why is Basic not widely used for functional programming? It all comes down to convenience. Functional programming requires immutable data and pure functions, so languages that make it easy to create and manipulate them are naturally the best choice.
On the other side, in terms of productivity, it’s beneficial to choose a multi-paradigm language: some problems are (still?) easier to solve with an object-oriented approach. I like Kotlin for this reason: it offers a good compromise between functional power and ease of use.
Making an effort to write code using pure functions and immutable data (as needed for referential transparency) can be a bit strange at the beginning, but it’s not particularly difficult. The difficult part is designing the application in a way that solves our problems while keeping the code easy to read and modify — which is exactly the same problem with object-oriented programming, if you think about it. So what is the difference? Well, as for me, it’s easier to attain those goals with a functional approach, particularly in the case of web application back-ends.
Thinking in Morphisms
In the book, I introduce the idea of thinking in morphisms. With this expression, I mean designing the application to focus on data transformations, rather than how to exchange messages among objects. I’m borrowing the “morphism” term from mathematics, and it corresponds in code to a pure function.
Most of the book is dedicated to showing how thinking in morphisms translates into practice — and we write a complete application following these principles. I even considered titling the book Thinking in Morphisms, but it didn’t work well as a title for a programming book.
Thanks for joining me on this journey. In the next two posts, I will give you a little taste of how thinking in morphisms works with a practical example. For reference, the code is on GitHub:
Update: you can find the second part here.
💬 If you are interested posts like this one, please follow me on Medium or on my twitter account, ramtop.
If you really really liked it, consider buying my book, From Objects to Functions:
You can save 35% off the ebook using promo code uboop_medium_35 now through July 31. Promo codes are not valid on prior purchases.
