Because code reuse is hard. Like, really hard. If it weren't we wouldn't be laughing at left-pad. If it weren't hard we wouldn't have so many front-end JavaScript frameworks. If it weren't Unreal wouldn't still have their own GC and std-like implementation today. Java wouldn't have been reinventing build system every five years.
The whole history of programming tool is exploring how to properly reuse code: are functions or objects the fundamental unit of reuse? is diamond inheritance okay? should a language have an official package management? build system? should C++ std have network support? how about gui support? should editors implement their own parsers or rely on language server? And none of these questions has a clear answer after thousands if not millions of smart people attempted. (well perhaps except the function vs object one)
Electron is the ultimate effort of code reuse: we reuse the tens of thousands of human-years invested to make a markup-based render engine that covers 99% of use case. And everyone complains about it, the author of OP article included.
LLM-coding is not code reuse. It's more like throwing hands up and admitting humans are yet not smart enough to properly reuse code except for some well-defined low level cases like compiling C into different ISA. And I'm all for that.
I think you could also argue that LLMs in coding are actually just a novel approach at code reuse: At the microscopic level, they excel at replicating known patterns in a new context.
(Many small dependencies can be avoided by letting the LLM just re-implememt the desired behavior; ~ with tradeoffs, of course)
The issue is orchestrating this local reuse into a coherent global codebase.
The problems with leftpad are a problem with the NPM ecosystem, not with code reuse as such. There are other dependency ecosystems that don't have these problems.
> Because code reuse is hard.
> humans are yet not smart enough to properly reuse code
All of these difficulties you outline are because program designs cater to the human developer experience over the machine.
If this weren't the case Python wouldn't exist because it's clearly not made with mechanical sympathy in mind. Dynamic languages as a whole would probably not exist.
It's because humans will never agree with eachother or with machines and that's what has led us to the proliferation of complexity and lack of reuse we see everywhere.
If this is what I think it is, I consider it very lopsided view, failure to recognize what model fits for what case and looking at everything from a hammer point of view
I think function is the fundamental unit and object is an extra level over it (it doesn't mean there is no use for object). Thinking objects/classes are the fundamental/minimal level is straight up wrong.
My opinion: Fundamental levels are data and operations (your functions). Not my view that class is a foundation. It is a representation convenient for some cases and not so much for other
The whole history of programming tool is exploring how to properly reuse code: are functions or objects the fundamental unit of reuse? is diamond inheritance okay? should a language have an official package management? build system? should C++ std have network support? how about gui support? should editors implement their own parsers or rely on language server? And none of these questions has a clear answer after thousands if not millions of smart people attempted. (well perhaps except the function vs object one)
Electron is the ultimate effort of code reuse: we reuse the tens of thousands of human-years invested to make a markup-based render engine that covers 99% of use case. And everyone complains about it, the author of OP article included.
LLM-coding is not code reuse. It's more like throwing hands up and admitting humans are yet not smart enough to properly reuse code except for some well-defined low level cases like compiling C into different ISA. And I'm all for that.