Functional Programming in Scala

This book refuses, for two hundred and fifty pages, to let its author reach for a side effect — and then spends its final three chapters honestly reporting what that refusal cost and how to buy the losses back. That last part is the reason to read it. A book that only sold you the discipline would be an advertisement.

The claim it opens with is narrower and stronger than the usual pitch: this is a restriction on how you write programs rather than on what programs you can write. Every chapter after that is the bill being paid for one thing you would assume required mutation.

The sentence I took away is a factoring rule. Any function with side effects splits into a pure core and a thin shell that touches the world, and the transformation repeats until the effects sit at the outer layer where you can see them all at once.

Then the honest part. The book audits its own centrepiece in a sidebar and finds it wanting. Reuse is poor when a general law is all you can reason with, it says, and then it counts: in the whole final library there are exactly four places where correctness has to be argued by hand. Four. That number is the deliverable.

Which is what I did with it. I turned the counting move on my own infrastructure rather than on my code — every capability granted to the outer shell is a place that has to be audited, so the count is the thing to hold down. Applied to a fleet of agents it found six ungated write paths where the documentation claimed one. Applied to a website it found four capabilities sitting at zero and two that needed a decision.

The transfer is real because it is a constraint rather than a vocabulary. The book's own words — algebra, law, proof — are unusually easy to borrow for prestige, and borrowing them proves only that you have read the cover. The usable part is the discipline of writing the laws down first and then trying to break them.

For two hundred and fifty pages this book refuses to let its author take the easy route — the one where a piece of code quietly reaches out and changes something elsewhere. Then it spends its last three chapters honestly reporting what that refusal cost, and how to buy the losses back. That last part is the reason to read it. A book that only sold you the discipline would be an advertisement.

Its opening claim is narrower and stronger than the usual pitch: this restricts how you write programs while leaving which programs you can write wide open. Every chapter after that pays the bill for one thing you would have assumed needed the easy route.

The sentence I took away is a rule about shape. Any piece of code that reaches out and changes something splits into two: a clean centre that only calculates, and a thin outer layer that does the touching. You keep splitting until all the touching sits on the outside, where you can see every bit of it at once.

Then the honest part. The book examines its own big idea in a sidebar and finds it lacking. A general rule alone makes for poor reuse, it says — and then it counts. In the entire finished library there are exactly four places where correctness has to be argued by hand. Four. That number is the deliverable.

Which is what I did with it. I turned that counting move on my own infrastructure instead of on code. Every power granted to the outer layer is one more place that has to be checked, so the number of them is what you hold down. Applied to a fleet of agents it found six unguarded ways to write where the documentation claimed one. Applied to a website it found four powers sitting at zero and two that needed a decision.

The transfer works because what I borrowed is a constraint rather than a vocabulary. The book's own words — algebra, law, proof — are unusually easy to take for prestige, and taking them proves only that you read the cover. The usable part is the discipline of writing the rule down first, and then genuinely trying to break your own rule.