[September 15th, 2024: I did not finish the book — and the notes are not organised as I later would start to; but it is indeed a fun and informative book and so I'd rather have it public. And it's also likely that I'll come around at some point.]

Chapter 1

A key takeaway from the first chapter is that code can be separated into actions, calculations, and data.

Calculations, in particular, are akin to mathematical functions, in the sense that the same input will always provide the same output - and it will also have no side-effects.

Chapter 2

Stratified design

There should be a clear image of the three main layers - Business Rules < Domain Rules < Tech Stack - in terms of frequency of change (how often to these have to be maintained). Business Rules changes the most often, while the Tech Stack is the underlying structure in which everything depends on.

Timeline Diagrams are also an important planning tool.

Chapter 3 - Distinguishing actions, calculations, and data

Chapter 4 - Extracting calculations from actions

or, as an alternate way to put it, tricks into refactoring old code.

Modifying global variables is an action. If possible, avoid global variables.

To extract a subroutine is to make a function of an action contained in some function, separating one function into two, where one calls the other. Ideally, the extracted piece of code is now a calculation.

Chapter 5 - Improving the design of actions

At this moment, business rules start to clearly arise in the code, and it is also important to make those functions as far away as possible from the underlying tech stack.

Chapter 6 - Staying immutable in a mutable language

A clear separation between reading and writing data, specially through the use of copy-on-write technique. All variables passed as arguments should not be directly modified. It is okay to copy a given structure and not modify all of it (say, an array with three items can get copied and just one of its contents changed).

Chapter 7 - Staying immutable with untrusted code

When dealing with legacy or generally untrusted code, it is still possible to maintain immutability of data. That is achieved using two (deep) copies of the data to be handled: one before passing it to the legacy code, and another when receiving the results of the legacy code. This is called defensive copying.

Chapter 8 - Stratified design

The concept is introduced, with a first chapter focusing on the pattern of straightforward implementations.

Keeping stuff at the same level of detail is interesting. One function should not mix lower- and higher-level operations. It seems to be indebted to the authors of SICP.