Program Comprehension

2024-08-17

I think that the key to better comprehension is isolation and constraining leakage - of information, of data, of control-flow.

Traditional function-based refactoring tries to reduce data leakage but doesn’t much recognize control-flow leakage.

For example, a function might call another function that is 1,000 lines away and there’s no constraint on which functions are nearby and which are far away.

Lambda parameter lists constrain which data you are allowed to use. Lambdas should, also, constrain which functions you are allowed to use - is that “dependency injection” and “OOP”?

But,,, the set of rules for writing functions in an acceptable manner so that dependency injection can be used is onerous. No mutation, no side-effects - the very things that CPUs were invented for. It is much simpler (IMO) to wrap the code in a “nano-process” (aka “closure”) with one input queue and one output queue. The rules for using that kind of thing become relaxed - do what thou will, as long as it’s only within the boundaries of your own “nano-process”, ensuring that communication with the outside world is only through queues that come with no guarantee of “when” their nano-process code will actually be executed.

See Also

References: https://guitarvydas.github.io/2024/01/06/References.html

Blog:

https://guitarvydas.github.io/

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/Jjx62ypR

Leanpub: https://leanpub.com/u/paul-tarvydas

Gumroad:

https://tarvydas.gumroad.com

Twitter: @paul_tarvydas