Book Review: From Objects to Functions
Review of the From Objects to Functions: Build Your Software Faster and Safer with Functional Programming and Kotlin by Uberto Barbini (2023).
TL;DR: Great book for advanced programmers who are interested in functional programming. I give it 10/10. I would recommend the book also for those who want to learn just about event-sourcing.
I was already interested in functional programming before I bought this book, but I had a hard time imagining a whole application written in a functional style. The book gently, step-by-step, introduces functional principles, and does it by writing a working application. After reading, I can say I understand concepts of functional programming, but mastering them will require a couple of real-life projects.
This book also actively teaches following topics:
- Event sourcing
- Hexagonal architecture
- CQRS
- Actor-based testing
- User stories
- TDD
Also touches/shows a bit of:
- Agile development
- Event storming
- Mock ups
- Acceptance (feature) tests
- Property Testing
- DDD
- REST
- Logs
- De/serialization
It’s a long list, and it’s also why do I like the book so much. It fits my thinking — both from agile and also technical point of view.
Good parts
Generally
Author introduces new functional concepts only when there is a need (usage) for them, and that is great. We see them immediately in action. We also don’t use a library for functional principles, and build everything from scratch, therefore the understanding is deep. Author as a teacher definitely succeeded.
Code
The book is full of code, and that is good — we’re programmers, right? The code is minimal enough, but fairly complete, a good balance.
I tried a few ways to understand code:
- Code everything by myself ahead. Great for learning, but had troubles to catch-up in the next chapter as the code examples were different from my implementation.
- Rewrite the code from the book to my code. Although I can type fast, this was a bad experience as I only typed code and didn’t focus on reasoning about it.
- Read a chapter from the book, then open the author’s code from github. This was a good approach as I had time to reason about the code. Once I was done, I opened the code in my IDE, browsed around to understand code parts at my own speed. And in the end programmed a bit of a new feature by myself. This approach gave me a lot.
Drawings
Ideas in the book might be difficult to grasp, but these drawings clarify everything…. Plus they are really pretty
Focus on Functors
Functors by themselves are a difficult topic. I’m glad that the author focuses on their explanation. Functors are the place where the complexity of functional programming is located.
Later the author explains for example Monads. Monads are just Functors with two new simple properties. The new topic is therefore pretty easy to understand — without any magic.
Theory
There is the right amount of theory — author always explains when something has a theoretical background with a couple of sentences and diagrams. Also adds sources/reference to the appendix to read more. But doesn’t overwhelm us with the theory.
It’s surprisingly not too difficult to understand the math behind, again by the great explanation. I’m also stunned how the math is expressed in Kotlin:
- Math: f: X ⟶ Y
- Kotlin: f: (X) -> Y
Practice
Each chapter is finished by a few exercises to practice. Sometimes they take just a few minutes to solve, so they easily help with the learning. Sometimes they are more challenging, and that is also good for more advanced/willing to work readers.
Gamebook
The book is full of references and feels like a game book. Don’t You know what is…? go to page 349! Aren’t You familiar with…? go to page 379!
Bad parts
Unfinished Code
Later in the book, the code is sometimes unfinished, uncompilable, or full of TODO(). It’s very difficult for me to understand what is going on when the idea is not explained fully, and the code doesn’t work.
When it’s a new topic (e.g. converting tests to DDT), then this style doesn’t help me at all. My preference in such situations is to explain fully -> code fully.
I understand why the author uses it for explaining — because it’s how he thinks — from outside -> in. Once I hit a topic that was familiar to me, I finally understood the flow.
Type Alias Obsession
Author uses a lot of type aliases. I dislike this practice as I have a hard time learning new topics, and at the same time I almost instantly forget what this new name (alias) means. I have to go back a couple of pages and realize that this is just a type alias, and in fact it means this simple concept.
I understand that in a living project where people are familiar with specific type aliases, they help. But they don’t help me to learn.
All in all, I’m glad that I’ve read this book. I’d like to thank Uberto Barbini. It’s a masterpiece.
