Yes. Anything that is destroyed during the process of compilation is not architecture. It is just a method of code organisation, and we've turned the subject into a holy war, pulling in mindshare that should be spent on more important problems (e.g. we have fibre lines and Ghz multi-core processors, but why are user interactions slower than they were in 1995?).
80% of code organisation problems require doing a couple of things right: directory design (directories, file names, file contents), function design (purpose, naming, parameters, context and return type). I've been coding for almost 25 years and I've encountered the balance "20%" extremely rarely. Even then, 100 lines of simple code is easier to read and modify than 20 lines wrapped in clever abstraction (e.g. I once had the dubious honour of refactoring a broken and unmaintainable state-machine driven code base back to a simple series of if/else/switch/case statements, and the improvement in the development and troubleshooting times seemed almost unfair for such a simple "trick").
This an amazing way to concisely explain the difference between indirection and abstraction. Works for me at least.
Anything undone by the compiler (perhaps even inlined) is just indirection. Everything beyond is actual abstraction (which cannot be broken down further by the compiler as it’s far too limited in its understanding).
Folks that have really strong opinions on issues of taste, but then they output apps that send a couple of thousand requests ( with several second latency ) are extremely difficult to reason with.
We do? In my neighborhood, we can’t get fiber lines because of some combination of NIMBYism and political back-scratching allowing a cable company to continue to serve us shit slow and unreliable internet. In the middle of a city!
I’m more interested in solving _those_ problems than how long a request round trip takes.
80% of code organisation problems require doing a couple of things right: directory design (directories, file names, file contents), function design (purpose, naming, parameters, context and return type). I've been coding for almost 25 years and I've encountered the balance "20%" extremely rarely. Even then, 100 lines of simple code is easier to read and modify than 20 lines wrapped in clever abstraction (e.g. I once had the dubious honour of refactoring a broken and unmaintainable state-machine driven code base back to a simple series of if/else/switch/case statements, and the improvement in the development and troubleshooting times seemed almost unfair for such a simple "trick").