4 comments

[ 2.9 ms ] story [ 29.0 ms ] thread
I understand and endorse the idea here.

It seems, though, that there must be some important distinction between "action at a distance" in physics, and "action at a distance" in software, that's being passed up.

In particular, "distance" in software is surely a function of "distance in mental space", rather than simply the number of lexical-scope boundaries crossed, or the specific number of containing modules. Do we have some way of formalizing this intuition of "distance", such that we could actually use it as a design measure?

Is there anything here that offers more insight than keeping your DB in the same datacenter as your app servers?
er, yes. "Locality" here doesn't mean keeping everything in the same place, physically - it's talking about keeping causes in the same modules as their effects. Different "space" entirely.
In particular, "distance" in software is surely a function of "distance in mental space", rather than simply the number of lexical-scope boundaries crossed, or the specific number of containing modules. Do we have some way of formalizing this intuition of "distance", such that we could actually use it as a design measure?

I think those metrics should converge on each other as you refine the shape of your program toward the Right Thing.

Rephrased: Your module or scoping system serves you well to the extent that you can make hierarchies of modules and scope correspond to hierarchies in your mental model.