I don't think the problem with prototype inheritance comes from whether people like creating things by taking something that already exists and modifying it. In fact, people very often use classical inheritance to emulate prototypical inheritance ("oh, i'll just add an extra method here and override that method there").
The problems normally relate to maintenance and change over time:
1. We reject classical-inheritance-emulating-prototypical-inheritance because it makes it hard to change the original. But copying a file and changing it doesn't have this problem, since the copy and the original are forks. If you need to make changes to both files, then you need to make changes to both files.
2. We prefer classical inheritance because a class is a description of how you can use an instance of that class. The class definition is usually very declarative and lends itself to great tooling support. Prototypical inheritance is imperative by its nature. This means there's no generic answer to the question, "How can I use this object", but only "how can I use this object right now?". But copying a file and changing it doesn't have this problem, since the copy and original are data, whose use is determined by external tools.
Another commenter in this thread specifically claims that prototypical inheritance was derived from this model (with a sense of optimism and joy, I think). But the fact that one extension of this model failed didn't mean the whole model is a failure. In this case, the suggestion is just to recognise what a user is doing and facilitate that. I think that's a lot less trouble than a language feature. (Actually, I think Jet Brains IDEs have a lot of features that tend towards this. They just might not be quite there.)
The problems normally relate to maintenance and change over time:
1. We reject classical-inheritance-emulating-prototypical-inheritance because it makes it hard to change the original. But copying a file and changing it doesn't have this problem, since the copy and the original are forks. If you need to make changes to both files, then you need to make changes to both files.
2. We prefer classical inheritance because a class is a description of how you can use an instance of that class. The class definition is usually very declarative and lends itself to great tooling support. Prototypical inheritance is imperative by its nature. This means there's no generic answer to the question, "How can I use this object", but only "how can I use this object right now?". But copying a file and changing it doesn't have this problem, since the copy and original are data, whose use is determined by external tools.
Another commenter in this thread specifically claims that prototypical inheritance was derived from this model (with a sense of optimism and joy, I think). But the fact that one extension of this model failed didn't mean the whole model is a failure. In this case, the suggestion is just to recognise what a user is doing and facilitate that. I think that's a lot less trouble than a language feature. (Actually, I think Jet Brains IDEs have a lot of features that tend towards this. They just might not be quite there.)