> I find this a very puzzling reply, and it may be that I misunderstood to what you are referring with the "they're" in "They're, for the most part, things we tried to put in libraries (or more ideally language standard libraries for a lot of things.)" It might refer to "the things Copilot does for you" or alternatively "the things you need to know yourself to be in industry."
I do see how that could be ambiguous. That's on me. I was referring to "the things Copilot does for you". Generally speaking trivial (or near trivial) algorithms.
> The thing is, regardless of which way you meant it, we need some people who can make the sort of libraries we need in part precisely because automation such as Copilot is no substitute
Fine. Some people might need to be able to implement and maintain libraries filled with generic algorithms, especially language maintainers. That's still a very different claim from the original "this is information that you're going to need if you actually want to go into the field". That claim implies that it's a universal requirement, whereas the reality is the vast majority probably don't need that knowledge.
Implementing these things is tedious, and results in a bunch of code that has to be maintained vs using something out of the standard library. For example, sort or max functions, which are at the intersection of what I see copilot generate a lot and intro to CS classes. Even without copilot, that's not really a skill that the average practitioner needs to have ready at all times, in fact I'd probably block a PR that implemented either of those things in my projects, it results in extra code that needs to be maintained and can be broken by a typo or something silly.
> The point about Larry Wall is that we don't get labor-saving tools without someone making an effort.
My comment about perl was sarcastic, and probably not helpful. That, also, is my bad.