This reads like a transcript of a therapy session. He never gives any real reasons. It's mostly a collection of assertions. This guy must never have worked on anything substantial. He also must underestimate the difficulty of writing software as well as his reliance on the work of others.
> I don’t like using code that I haven’t written and understood myself.
Why stop with code? Why not refine beach sand to grow your own silicon crystal to make your own processor wafers?
Division of labor is unavoidable. An individual human being cannot accomplish all that much.
> If you’re not writing in binary, you don’t get to complain about an extra layer of abstraction making you uncomfortable.
This already demonstrates a common misconception in the field. The physical computer is incidental to computer science and software engineering per se. It is an important incidental tool, but conceptually, it is incidental. Binary is not some "base reality" for computation, nor do physical computers even realize binary in any objective sense. Abstractions are not over something "lower level" and "more real". They are the language of the domain, and we may simulate them using other languages. In this case, physical computer architectures provide assembly languages as languages in which we may simulate our abstractions.
Heck, even physical hardware like "processors" are abstractions; objectively, you cannot really say that a particular physical unit is objectively a processor. The physical unit simulates a processor model, its operations correspond to an abstract model, but it is not identical with the model.
> My control freakery is not typical. It’s also not a very commercial or pragmatic attitude.
No kidding. It's irrational. It's one thing to wish to implement some range of technology yourself to get a better understanding of the governing principles, but it's another thing to suffer from a weird compulsion to want to implement everything yourself in practice...which he obviously isn't doing.
> Abstractions often really do speed up production, but you pay the price in maintenance later on.
What? I don't know what this means. Good abstractions allow us to better maintain code. Maintaining something that hasn't been structured into appropriate abstractions is a nightmare.
>> Abstractions often really do speed up production, but you pay the price in maintenance later on.
> What? I don't know what this means. Good abstractions allow us to better maintain code. Maintaining something that hasn't been structured into appropriate abstractions is a nightmare.
100% agree with this. Name it well, maintain it in one place ... profit.
It's the not abstracting up front that can catch you: The countless times I have been asked to add feature x, but that it is a one-off/PoC. Which sometimes even means it might not get the full TDD/IoC/feature flag treatment (which aren't always available depending upon the client's stack).
Then, months later get asked to created an entire application or feature set on top of that. Abstracting that one-off up into a method/function/class tags and bags it: it is now named and better documented. Can be visible in IDE, called from anywhere and looped over if need be.
There is obviously a limit to where the abstraction juice isn't worth the squeeze, but otherwise, it just adds superpowers as time goes on.
> I don’t like using code that I haven’t written and understood myself.
Why stop with code? Why not refine beach sand to grow your own silicon crystal to make your own processor wafers?
Division of labor is unavoidable. An individual human being cannot accomplish all that much.
> If you’re not writing in binary, you don’t get to complain about an extra layer of abstraction making you uncomfortable.
This already demonstrates a common misconception in the field. The physical computer is incidental to computer science and software engineering per se. It is an important incidental tool, but conceptually, it is incidental. Binary is not some "base reality" for computation, nor do physical computers even realize binary in any objective sense. Abstractions are not over something "lower level" and "more real". They are the language of the domain, and we may simulate them using other languages. In this case, physical computer architectures provide assembly languages as languages in which we may simulate our abstractions.
Heck, even physical hardware like "processors" are abstractions; objectively, you cannot really say that a particular physical unit is objectively a processor. The physical unit simulates a processor model, its operations correspond to an abstract model, but it is not identical with the model.
> My control freakery is not typical. It’s also not a very commercial or pragmatic attitude.
No kidding. It's irrational. It's one thing to wish to implement some range of technology yourself to get a better understanding of the governing principles, but it's another thing to suffer from a weird compulsion to want to implement everything yourself in practice...which he obviously isn't doing.
> Abstractions often really do speed up production, but you pay the price in maintenance later on.
What? I don't know what this means. Good abstractions allow us to better maintain code. Maintaining something that hasn't been structured into appropriate abstractions is a nightmare.