Abstractions have their place, but the evolution of my 15 year career has led me to use them as a last resort when I find myself needing to copy code more than twice.
Abstractions have their place, but the evolution of my 15 year career has led me to use them as a last resort when I find myself needing to copy code more than twice.
It's a pity that so few of our programming languages distinguish between these two quite different concepts.
The only language I use that differentiates between functions and procedures is PostgreSQL, and to be honest I find the distinction pretty annoying in practice. One can return values, the other can control transactions. So when refactoring code you sometimes need to make a function a procedure or vice versa and it's a pain. (As a consequence, I try to always use functions to make things easier)
This is the sort of advice that can quickly become a thought terminator because the writer has so much authority.
10 or 20 small functions with no nesting inside still has all the complexity, but none of the structure to help programmer understand it.
Functions can be called in any order, any number of times, and you have to trace the full call-stack in your mind and keep it there to get the same understanding of what happens that you had just by looking at the linear code.