Comment by 1718627440
13 hours ago
> If you are just writing a large volume of code over and over again
But why would you do that? Wouldn't you just have your own library of code eventually that you just sell and sell again with little tweaks? Same money for far less work.
People, at least novice developers, tend to prefer fast and quick boilerplate that makes them look effective, over spending one hour sitting just thinking and designing, then implementing some simple abstraction. This is true today, and been true for as long as I've been in programming.
Besides, not all programming work can be abstracted into a library and reused across projects, not because it's technically infeasible, but because the client doesn't want to, cannot for legal reasons or the developer process at the client's organization simply doesn't support that workflow. Those are just the reasons from the top of my head, that I've encountered before, and I'm sure there is more reasons.
With today’s languages, small differences in specs per context can make rolling out similar code many times, with key differences, the right thing to do.
As an alternative to:
1. Once again, creating a new tool stack, language, library, or framework that generalizes well up to a point but isn’t the final word, so another cycle of slightly different bespoke code on that, repeat.
Or the dual problem:
2. Investing in using the helpful abstraction handling dependencies of the day, that work fine and reduce new code considerably, but will be harder to reason about later after a series of better, newer, more popular with the new crowd, alternate dependencies are adopted and discarded over time. Leaving a trail of fewer, but more deeply different implementations. In addition to amplifying dependency risks such as code rot.
Until our coded abstractions become more flexible and stable over time, the price will be massive quantities of similar code.