When we ask ourselves: "how should we structure our code?", the primary goal should be: so that it's easily visualizable and debuggable. Our guiding principles at the moment are all over the place. For a long time it was: make code testable. Then we had things like: eliminate side-effects, immutability, one-way data flow, static type-checkable, etc.
The problem is that by ignoring visualizability, when you do come to visualize it (which everyone inevitably needs to when reading code and building a mental model), it's this huge tangled mess. People forget that the purpose of structuring code is to make it easy for HUMANS to understand. The computer only understands assembly at the end of the day. So anything beyond that is suppose to be for our benefit.
When we ask ourselves: "how should we structure our code?", the primary goal should be: so that it's easily visualizable and debuggable. Our guiding principles at the moment are all over the place. For a long time it was: make code testable. Then we had things like: eliminate side-effects, immutability, one-way data flow, static type-checkable, etc.
The problem is that by ignoring visualizability, when you do come to visualize it (which everyone inevitably needs to when reading code and building a mental model), it's this huge tangled mess. People forget that the purpose of structuring code is to make it easy for HUMANS to understand. The computer only understands assembly at the end of the day. So anything beyond that is suppose to be for our benefit.