> They're, for the most part, things we tried to put in libraries.

We need some people who can do things like making those libraries. It also seems plausible that the people who have at least some of the knowledge and judgement to do that effectively will, on average, be more effective on more mundane tasks as well.

Larry Wall is one who wrote (somewhat drolly) about the virtues of laziness, but there was nothing lazy about what he did.

> We need some people who can do things like making those libraries.

Do we? For things as simple as copilot tends to put out? Why?

Do you also believe we need to keep people around that do other automated things? Plowing fields by hand? Hand compiling higher level languages (as the first lisp compiler was bootstrapped)?

I mean, keep the information around. Don't go burning textbooks on subjects just because we automated something. But, what exactly is the value proposition of having students do these things?

> It also seems plausible that the people who have at least some of the knowledge and judgement to do that effectively will, on average, be more effective on more mundane tasks as well.

And your claim is also that this is the only way to get the requisite knowledge and judgement? Have students take in a string from stdin with a format that changes every semester, munge it around, and do things with it instead.

> Larry Wall is one who wrote (somewhat drolly) about the virtues of laziness, but there was nothing lazy about what he did.

As someone who has done string munging in C, I'm not entirely convinced that creating perl isn't an effort saving defense mechanism (only half joking).

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."

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 (at least not yet.)

This observation does not (and is not intended to) endorse current methods of instruction or hiring; on the contrary, it supports spcebar's view that riding your way to a degree, certificate or entry-level position on the back of Copilot is not doing yourself any favors.

The point about Larry Wall is that we don't get labor-saving tools without someone making an effort.

> 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.

To be clear, I take it that you are saying that a) everything Copilot is currently capable of can be found in libraries, and consequently b) learning how to do those things oneself is a waste of time, so c) it does not matter if people entering industry as software developers cannot do that themselves.

My point is that even if this is the case for a majority of such people, we still need the people who make all the library contents that are beyond Coplilot's capabilities, and we both seem to agree that its capabilities are limited.

The thing is, a world in which a lot of people can be productive software developers, without even being capable of writing the sort of algorithms Copilot is capable of, is highly dependent on the people who design and write the libraries that implement not only those algorithms, but also a great deal else that is beyond Copilot's capabilities. The industry may not need everyone to be able to do that, but then it is entirely dependent on those who can.

One can certainly argue that there is no point in an education that stops at the ability to reproduce what Copilot does, but that would be something of a straw man, as education does not typically stop there. I agree that it makes a poor hiring benchmark, regardless of the role being filled.

> To be clear, I take it that you are saying that...

I'm going to answer these individually because the answers are all different.

> a) everything Copilot is currently capable of can be found in libraries,

The vast majority, perhaps not 100%.

> b) learning how to do those things oneself is a waste of time

It's a waste of time if the pupil doesn't actually want to do it. If they do want to do it, there's probably quite a bit of value to be had. It's personal value for the student, not as a field.

Sort of like how I got quite a bit of value out of reading the old ITS documentation I found on github once, but I don't think I'd recommend it as part of the standard CS curriculum.

> c) it does not matter if people entering industry as software developers cannot do that themselves.

Correct. Assuming cannot means "without googling".

> My point is that even if this is the case for a majority of such people, we still need the people who make all the library contents that are beyond Coplilot's capabilities, and we both seem to agree that its capabilities are limited.

Sure, but that's a relatively small number of people. My point is that if using these tasks to measure aptitude is causing you problems because copilot exists, it's perfectly fine to just use something else.

> The thing is, a world in which a lot of people can be productive software developers, without even being capable of writing the sort of algorithms Copilot is capable of, is highly dependent on the people who design and write the libraries that implement not only those algorithms, but also a great deal else that is beyond Copilot's capabilities. The industry may not need everyone to be able to do that, but then it is entirely dependent on those who can.

Fair, but that's already the situation we're in with programming languages. We're entirely dependent on those as a field, and the vast majority of practitioners wouldn't be able to create a compiler or be anywhere near competent in language design. I would put the large frameworks (e.g. spring) in the same category.

These trivial algorithms become like the opcodes for a particular processor. Someone has to know them, but basically everybody not working on a compiler can ignore it (unless it particularly tickles your fancy).

I do have one small issue with your wording, however. Specifically the use of the word "capable" in this bit:

> without even being capable of writing the sort of algorithms Copilot is capable of

The people going into the field definitely need to be capable of implementing these sorts of algorithms. You're going to fail at so much of software if you aren't capable of something that trivial. It just doesn't need to be taught. These algorithms can be looked up if they're ever required. The ones that come up frequently will be naturally memorized and the others won't. This is a field where you have to learn new things, often without any sort of available expert in the subject, likely this will happen with an entire language or how to use a particular library.

I'm comfortable with copilot the same way I am comfortable with a calculator. Sure, if you have to, you should be able to do a logarithm with a slide rule, but I'm ok with not teaching university students how to use a slide rule. And if a professor assigned a bunch of homework under the assumption that students were going to use a sliderule, and the students all used calculators, I'd tell them to just drop that particular lesson.

We have reached a point of mutual understanding and considerable agreement, but I feel we have circled around to the original problem.

In your last paragraph, you consider the case of calculator vs. slide rule, but one can, I think, make a more apposite case with calculator vs. learning arithmetic (and even if you don't agree that it is more apposite, the point can still be made!) By your logic, we should not be assigning any arithmetic problems that can be solved with a calculator.

But why stop there? Even current calculators can do much more than basic arithmetic, and their capabilities pale in comparison to those of general-purpose computers. I do not believe you can teach mathematics in a way that begins at a point beyond what has been automated, and before long that may be true for computing as well. This has not led to the demise of mathematics education, and neither will it for computing, for the same reason in both cases: anyone who needs to use these tools to get through the introductory classes will wash out later - which brings us right back to spcebar's original comment about only hurting themselves in the long run.

> I think, make a more apposite case with calculator vs. learning arithmetic (and even if you don't agree that it is more apposite, the point can still be made!) By your logic, we should not be assigning any arithmetic problems that can be solved with a calculator.

I think that's an excellent point, and one whose nuances shouldn't be un-examined.

I guess the difference to me is that arithmetic feels more fundamental. I may be using fundamental in a weird way here, but I don't mean it in the sense of something that you build on. I mean it in the sense that arithmetic itself is the idea that's trying to be taught. Whereas a sorting algorithm has both a explanation as a semi-platonic ideal and as an implementation and they're very different things. You can fairly effectively wield the implementation only using the idea in your head, mostly regardless of your understanding of the implementation. In fact, it's generally considered good practice to hide an implementation from your eventual users.

I'm not so convinced that you could do the same with arithmetic, although I'm open to arguments to the contrary.

Now that I'm thinking about it, I think this is the dividing line between math and computing in my head. The ability to separate out the real world part from the ideal and operate the former using only the latter.

Perhaps I'm mistaken, but I would be very surprised if a mathematician could operate without understanding arithmetic, but I've seen quite competent programmers construct APIs just fine without having been taught sorting algorithms.