It's exacerbated by the tendency to factor a single function into many simpler ones.
That's an interesting comment. I often wonder about where the "sweet spot" of expression lies. If you break things up into too many small things, it's confusing. But a huge monolithic entity is also confusing. What's the "right level of decomposition?"
I think this is closely related to why 'naming things' is hard. Small functions do one thing and are easy to name, larger things do more than one thing and are harder to name. But very small functions, smaller than useful leads to harder names as well!
This does not directly answer your question but I think a good sign that you're on the wrong track is when naming things gets harder, that's when you've decomposed too far.
Great answer, thanks. It makes me think about sudden domain shifts. "Fetch the list of users. Locate the user matching the description. Push the user object onto the stack." The last item shifts from the business domain into implementation details, and it probably shouldn't be "close" to the others.
I think this is closely related to why 'naming things' is hard.
I find this especially problematic in exploratory and experiment-driven programming because naming things often gets in the way until code has stabilized somewhat.
For this reason, I've found working in Max/MSP extremely pleasant because you don't need to name things unless it makes sense to. Yes a lot of Max code you see online is a mess of lines, but I found the key is that if you do, in fact, split related things into their own named components, then I hit the sweet spot between not being required to name things that don't have natural names (or at least deferring doing so until I'm done experimenting and trying things) and still maintaining good software practices, maintainability and abstraction.
I've always thought of a hyper-abstracted codebase being like a binary tree, lazy code being like a linked list, and optimal code being like a B-tree tuned for the page size and seek latency of your particular brain.
>If you break things up into too many small things, it's confusing.
Not if you're disciplined about it.
>What's the "right level of decomposition?"
The key is not to decompose your whole problem into a network of tightly coupled parts. It's far better to build up your language with layers of abstraction until you have a new language which makes your problem trivial to express.
That's an interesting comment. I often wonder about where the "sweet spot" of expression lies. If you break things up into too many small things, it's confusing. But a huge monolithic entity is also confusing. What's the "right level of decomposition?"