4 ms·

> this is information that you're going to need if you actually want to go into the field and if you're using copilot here you are damaging yourself in the long

by Kamq 4y ago

> this is information that you're going to need if you actually want to go into the field and if you're using copilot here you are damaging yourself in the long run When you say into the field, do you mean academia or industry? Because the things copilot does for you are absolutely not the things you need to know yourself to be in industry. They're, for the most part, things we tried to put in libraries (or more ideally language standard libraries for a lot of things). The fact that is solves a lot of interview questions just means our interview process was absolutely garbage. And I'm skeptical of the academic side of this as well. It sounds like professors from the early 60s being annoyed that students have compilers (another tool that saves a ton of work and repetition). Y'all are forgetting that this is the ultimate lazy man's field. This isn't the first time the basics have been swept away and replaced with something easier to work with (and hopefully won't be the last).

mannykannot 4y ago
> 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.
- Kamq 4y ago
  > 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).
  - deleted 4y ago
    [deleted]
  - mannykannot 4y ago
    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.
    - Kamq 4y ago
      > 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.

by Kamq 4y ago

mannykannot 4y ago

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

Kamq 4y ago
> 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).
- deleted 4y ago
  [deleted]
- mannykannot 4y ago
  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.
  - Kamq 4y ago
    > 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.