6 ms·

Calling it now, there will be a "Copilot considered harmful" post. If you need to go through the suggested code to ensure it's correct, you may as well write i

by theden 5y ago

Calling it now, there will be a "Copilot considered harmful" post. If you need to go through the suggested code to ensure it's correct, you may as well write it yourself? If you glance at it and it looks about right, you can potentially overlook bugs or edge cases, you'll lose confidence in your own code since you didn't properly conceptualise it yourself. Potentially for newer developers it robs them of active experience of writing code. Much like learning an instrument, improvisation, or say physics, a lot of people learn by doing it, even if it's grunt work. IMO this is necessary for any professional. Maybe it will be seen as a crutch, maybe I'm getting old? I have tons of code snippets, but it's usually stuff I've written and understood and battle tested, even if it was initially sourced from SO. Having it in the text editor and appear out of nowhere with no context seems like it'd need some adjustment in apprehension. Edit: I should have been clear, I'm not against others using Copilot and will try it out myself. I can see it being useful in replacing one-line libs like in nodejs, i.e., copying a useful well-known and needed snippet vs installing yet another lib that could be a sec issue. Also the industry is the real gatekeeper—we have tools that don't require us to repeat prior-art, yet have to go through hurdles of leetcode-style interviews for a job. Maybe in the future the hardest part of being a (AI-driven) developer will be getting a job?

j2kun 5y ago
I imagine, for a while the complexity that Copilot can handle is limited to what most people would pull from stackexchange anyway. And if it helps autocomplete documentation and provide automatically generated (more descriptive) function/variable names, it will probably be a net positive for those limited use cases. That said, I can't wait to read the first postmortem where someone deployed code generated via Copilot that has a bug. I just hope it's not on a rocketship or missile guidance system.
aerovistae 5y ago
> Potentially for newer developers it robs them of active experience of writing code. And for those with experience, this will be obvious when reviewing their code. There's only two possibilities -- either copilot will get so good that it won't matter, or code written by copilot will have obvious tells and when someone is over-relying on it to cover up for a lack of knowledge, that will be very clear from repetition of the same sorts of mistakes.
brown9-2 5y ago
All of the same can be said for copy-and-pasting code you find in a tutorial in Google search results or in a Stack Overflow answer. This just seems to be automating that process even further.
- theden 5y ago
  Those extra steps can be valuable, since you'll have to work to even find the right code to copy/paste, and the context which it's in can teach you something. Even something as simple as copying from the docs, it's usually a good place to signal deprecation, use-case applicability, API updates etc. you lose all that with the automation. Oftentimes there's also discussion around a solution, and in many ways can swing one's decision on whether to use the code or not.
crazygringo 5y ago
> If you need to go through the suggested code to ensure it's correct, you may as well write it yourself? Not really. People are generally far faster at reading something and evaluating whether it's correct, than at writing something. In the same way it's faster to read a book than to write one. Not to mention the time it takes typing, fixing typos, etc. So this could genuinely be a huge timesaver if it helpful enough of the time.
- theden 5y ago
  idk I always find writing code easier than reading code. Perl is a fantastic example of this.
- layla5alive 5y ago
  I completely disagree with you. Reading code for correctness is difficult and not something most people do well at all. Reading code and reading for correctness are not the same, and most developers can write code a lot faster than they can verify it.
  - dgb23 5y ago
    That’s what a REPL and automated tests are for.
    - layla5alive 5y ago
      Automated tests find all bugs and replace code review? I'd love some of those drugs!
      - dgb23 5y ago
        No, of course not. I meant understanding what you write, while you write it. Also to add a bit of nuance: I typically spend much more time reading and thinking rather than writing. But I read REPL output, logs, test output just as much, sometimes more than the actual code.
  - crazygringo 5y ago
aj3 5y ago
Honestly, this attitude (dismissing the feature even without trying it out) comes across as insecurity and gatekeeping.
- auggierose 5y ago
  Nope, it's called wisdom. Not everyone on here is under 12.
  - joshbert 5y ago
    There's that insecurity thing he was talking about.
    - auggierose 5y ago
      Not sure what is confident about doing pair programming with an AI, josh.
- jpttsn 5y ago
  Is “you’re gatekeeping!” the new “first comment!”? I fail to see the information gain from adding this message to every thread.
dgb23 5y ago
I honestly think this is solving a real problem with commonly used languages and their lack of syntax abstraction and expressiveness. I can imagine this being very useful in helping to type out what I consider to be „mechanical noise“: Things that you have to type out to satisfy an expression rather than to convey semantics. A good example of how this type of noise manifests: Observe two programmers, both being similarly strong in terms of many concepts except for mechanical expertise. One uses the editor as an extension of their body, it’s beautiful to watch, the other stumbles awkwardly over the code until it’s finished. You can observe the latter in programmers who are very smart and productive, but they either didn’t train their mechanics deliberately or maybe they lack that kind of baseline eye hand coordination.
- shadowgovt 5y ago
  It is even entirely possible that this approach hits a middle-ground that serves the corporate software-development space better than highly-flexible languages. The difficulty with high flexibility is that the expressions become very domain-specific very quickly, creating the challenge of learning the new abstractions. So one isn't just a LISP developer, one knows how to write in the specific forest of macros that have been built up around one specific problem domain. The end result is code that means nothing to a reader who doesn't have a dense forest of macro definitions in their brain (at least in this era, their IDE will likely helpfully pull up the macro definitions with a mouse-over or cursor-over gesture!). Contrast with this approach, where the complexity of abstraction is being baked into the lower-flexibility language. The code is less dense, and that's a tradeoff... But grab any 10 developers off the street with experience in that language and have them read it and 8 of them will likely be able to tell you with some accuracy what the code is doing. Not a trick I've seen possible with even very experienced LISP developers on a codebase they've never seen before. ... and, of course, being able to grab a random 10 developers off the street and have 8 of them up-to-speed in no time at all is crack cocaine to big businesses with large and complex systems maintained by dozens, hundreds, or thousands of people.
  - dgb23 5y ago
    I’ve seen macro heavy code that is very semantic and declarative. It’s a powerful tool, so it is natural that people need to learn and fail until they use it well.
manquer 5y ago
Think of it as a junior dev working under you and doing the grunt work of typing in your ideas. Sometimes he can StackOverflow a better snippet than you can write on your own, you will probably learn a bit from it, but it won't surprise you. It is no different from a code review of another perhaps junior dev and only doing adding finishing touches. There is plenty of boilerplate you have to write, Intellisense/ Auotfill only goes so far, this is next step in the evolution. Sure it is not perfect but if i can express my ideas faster, why not. Also It is a very probably poor tool for new devs, they won't know that suggestion maybe not the best and probably won't ignore it when it is wrong as they won't know any better.
- asdfman123 5y ago
  Most people on HN will probably be fine for a while. This innovation though, once properly developed, could completely screw over anyone wanting to enter programming. Code completion might be the new "junior dev."
  - manquer 5y ago
    All the computer scientists[1] at one point considered software developers and IT in the same light as higher level tooling evolved . While sure purist view is not wrong that average quality of outcome has dropped since 70s-80s, the quantum of throughput meant that impact has been positive and immense. Similarly I am expecting this kind of tooling would open up to more types of new developers. [1] all the mathematicans thought similarly perhaps during 50s and 60s.
Nicholas_C 5y ago
As a hobbyist this is going to save me so much time. Little things like googling how to read CSVs in python for the 20th time add up and I think this should help solve that.
shadowgovt 5y ago
I'm not quite old enough to remember: when high level languages like C gained wide adoption, how much pushback was there from the philosophy that if you're not writing it in assembly, you're not really writing code?

by theden 5y ago

j2kun 5y ago

I imagine, for a while the complexity that Copilot can handle is limited to what most people would pull from stackexchange anyway. And if it helps autocomplete documentation and provide automatically generated (more descriptive) function/variable names, it will probably be a net positive for those limited use cases. That said, I can't wait to read the first postmortem where someone deployed code generated via Copilot that has a bug. I just hope it's not on a rocketship or missile guidance system.

aerovistae 5y ago

> Potentially for newer developers it robs them of active experience of writing code. And for those with experience, this will be obvious when reviewing their code. There's only two possibilities -- either copilot will get so good that it won't matter, or code written by copilot will have obvious tells and when someone is over-relying on it to cover up for a lack of knowledge, that will be very clear from repetition of the same sorts of mistakes.

brown9-2 5y ago

All of the same can be said for copy-and-pasting code you find in a tutorial in Google search results or in a Stack Overflow answer. This just seems to be automating that process even further.

theden 5y ago
Those extra steps can be valuable, since you'll have to work to even find the right code to copy/paste, and the context which it's in can teach you something. Even something as simple as copying from the docs, it's usually a good place to signal deprecation, use-case applicability, API updates etc. you lose all that with the automation. Oftentimes there's also discussion around a solution, and in many ways can swing one's decision on whether to use the code or not.

crazygringo 5y ago

> If you need to go through the suggested code to ensure it's correct, you may as well write it yourself? Not really. People are generally far faster at reading something and evaluating whether it's correct, than at writing something. In the same way it's faster to read a book than to write one. Not to mention the time it takes typing, fixing typos, etc. So this could genuinely be a huge timesaver if it helpful enough of the time.

theden 5y ago
idk I always find writing code easier than reading code. Perl is a fantastic example of this.
layla5alive 5y ago
I completely disagree with you. Reading code for correctness is difficult and not something most people do well at all. Reading code and reading for correctness are not the same, and most developers can write code a lot faster than they can verify it.
- dgb23 5y ago
  That’s what a REPL and automated tests are for.
  - layla5alive 5y ago
    Automated tests find all bugs and replace code review? I'd love some of those drugs!
    - dgb23 5y ago
      No, of course not. I meant understanding what you write, while you write it. Also to add a bit of nuance: I typically spend much more time reading and thinking rather than writing. But I read REPL output, logs, test output just as much, sometimes more than the actual code.
- crazygringo 5y ago

aj3 5y ago

Honestly, this attitude (dismissing the feature even without trying it out) comes across as insecurity and gatekeeping.

auggierose 5y ago
Nope, it's called wisdom. Not everyone on here is under 12.
- joshbert 5y ago
  There's that insecurity thing he was talking about.
  - auggierose 5y ago
    Not sure what is confident about doing pair programming with an AI, josh.
jpttsn 5y ago
Is “you’re gatekeeping!” the new “first comment!”? I fail to see the information gain from adding this message to every thread.

dgb23 5y ago

I honestly think this is solving a real problem with commonly used languages and their lack of syntax abstraction and expressiveness. I can imagine this being very useful in helping to type out what I consider to be „mechanical noise“: Things that you have to type out to satisfy an expression rather than to convey semantics. A good example of how this type of noise manifests: Observe two programmers, both being similarly strong in terms of many concepts except for mechanical expertise. One uses the editor as an extension of their body, it’s beautiful to watch, the other stumbles awkwardly over the code until it’s finished. You can observe the latter in programmers who are very smart and productive, but they either didn’t train their mechanics deliberately or maybe they lack that kind of baseline eye hand coordination.

shadowgovt 5y ago
It is even entirely possible that this approach hits a middle-ground that serves the corporate software-development space better than highly-flexible languages. The difficulty with high flexibility is that the expressions become very domain-specific very quickly, creating the challenge of learning the new abstractions. So one isn't just a LISP developer, one knows how to write in the specific forest of macros that have been built up around one specific problem domain. The end result is code that means nothing to a reader who doesn't have a dense forest of macro definitions in their brain (at least in this era, their IDE will likely helpfully pull up the macro definitions with a mouse-over or cursor-over gesture!). Contrast with this approach, where the complexity of abstraction is being baked into the lower-flexibility language. The code is less dense, and that's a tradeoff... But grab any 10 developers off the street with experience in that language and have them read it and 8 of them will likely be able to tell you with some accuracy what the code is doing. Not a trick I've seen possible with even very experienced LISP developers on a codebase they've never seen before. ... and, of course, being able to grab a random 10 developers off the street and have 8 of them up-to-speed in no time at all is crack cocaine to big businesses with large and complex systems maintained by dozens, hundreds, or thousands of people.
- dgb23 5y ago
  I’ve seen macro heavy code that is very semantic and declarative. It’s a powerful tool, so it is natural that people need to learn and fail until they use it well.

manquer 5y ago

Think of it as a junior dev working under you and doing the grunt work of typing in your ideas. Sometimes he can StackOverflow a better snippet than you can write on your own, you will probably learn a bit from it, but it won't surprise you. It is no different from a code review of another perhaps junior dev and only doing adding finishing touches. There is plenty of boilerplate you have to write, Intellisense/ Auotfill only goes so far, this is next step in the evolution. Sure it is not perfect but if i can express my ideas faster, why not. Also It is a very probably poor tool for new devs, they won't know that suggestion maybe not the best and probably won't ignore it when it is wrong as they won't know any better.

asdfman123 5y ago
Most people on HN will probably be fine for a while. This innovation though, once properly developed, could completely screw over anyone wanting to enter programming. Code completion might be the new "junior dev."
- manquer 5y ago
  All the computer scientists[1] at one point considered software developers and IT in the same light as higher level tooling evolved . While sure purist view is not wrong that average quality of outcome has dropped since 70s-80s, the quantum of throughput meant that impact has been positive and immense. Similarly I am expecting this kind of tooling would open up to more types of new developers. [1] all the mathematicans thought similarly perhaps during 50s and 60s.

Nicholas_C 5y ago

As a hobbyist this is going to save me so much time. Little things like googling how to read CSVs in python for the 20th time add up and I think this should help solve that.

shadowgovt 5y ago

I'm not quite old enough to remember: when high level languages like C gained wide adoption, how much pushback was there from the philosophy that if you're not writing it in assembly, you're not really writing code?