Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Copilot

copilot.github.com

Post reply on HN
Print view View original

461–470 of 1001 posts

Re: GitHub Copilot

#461

Post by shoguning »

hn_throwaway_99 wrote: post #415
anthropodie wrote: post #335

Earlier quoted context omitted.

Few days back, Sam Altman tweeted this "Prediction: AI will cause the price of work that can happen in front of a computer to decrease much faster than the price of work that happens in the physical world. This is the opposite of what most people (including me) expected, and will have strange effects" And I was like yeah I gotta start preparing for next decade.

I think this will result in classic Jevons paradox: https://en.wikipedia.org/wiki/Jevons_paradox . As the price of writing any individual function/feature goes down, the demand for software will go up exponentially. Think of how many smallish projects are just never started these days because "software engineers are too expensive". I don't think software engineers will get much cheaper, they'll just do a lot more.

I'm guessing low expertise programmers whose main contribution was googling stackoverflow will get less valuable, while high expertise programmers with real design skill will become even more valuable.

Re: GitHub Copilot

#462

Post by ConceptJunkie »

as300 wrote: post #211
mdellavo wrote: post #193

Earlier quoted context omitted.

What do you think about this being overall detrimental to code quality as it allows people to just blindly accept completions without really understanding the generated code. Similar to copy-and-paste coding. The first example parse_expenses.py uses a float for currency - that seems to be a pretty big error that's being overlooked along with other minor issues around no error handling. I would say the quality of the…

Why would you say it's an error to use a float for currency? I would imagine it's better to use a float for calculations then round when you need to report a value rather than accumulate a bunch of rounding errors while doing computations.

Because it's an error to use floats in almost every situation. And currency is something where you don't want rounding errors, period. The more I've learned about floating point numbers over the years, the less I want to use them. Floats solve a specific problem, and they're a reasonable trade-off for that kind of problem, but the problem they solve is fairly narrow.

Re: GitHub Copilot

#463

Post by mdellavo »

throwaway675309 wrote: post #454
inimino wrote: post #385

I'm amazed to see how positive the overall response is to this idea. Almost as if programmers think that writing programs is the worst part of the job and ready to be automated away. As someone more aligned with the Dijkstra perspective, this seems to me like one of the single worst ideas I've ever seen in this domain. We already have IDEs and other tools leading to an increase in boilerplate and the acceptance of it…

I mean you say this, but you and most likely the majority of programmers rely on dozens of repositories, packages and libraries with likely zero deep understanding of it (and at the very least haven't read the source code of ) so I don't really understand the difference here. The advantage of something like this is that instead of having to go to stack overflow or any number of reference sites and copy pasta it can j…

if you are typing out boilerplate you should look to abstract it away

Re: GitHub Copilot

#464

Post by staticassertion »

UnFleshedOne wrote: post #452
staticassertion wrote: post #437

Earlier quoted context omitted.

> Almost as if programmers think that writing programs is the worst part of the job and ready to be automated away. writing the programs is definitely boring garbage work. Typing is so slow and annoying - hence autocomplete being a standard tool. This is, to me, just fancy autocomplete. > to an increase in boilerplate and the acceptance of it because they make it easier to manage. Boilerplate optimizes for the right…

Boilerplate is only easier to read and analyze if you can be sure it is consistent, so you can tune it out. Usually though, there is this one getter method that is not quite like the others and you literally will not see the difference until it bites you. We'll need more IDE enhancements, to highlight interesting pieces and desaturate standard boilerplate...

When I think of boilerplate I think of context that is made explicit. Things like type annotations, longer variable names, the lifetime or attributes of some class or data etc. These things are extremely helpful for a number of things - they convey context from writer to readers, they aid in proving the code correct, and they can make code faster.

The context almost always exists in the writers head. We all have a specification of our program based on our expectations, and we type out code to turn that model into an implementation. We only spend so much time conveying that model though - most of us don't write formal proofs, but many of us will write out type annotations or doc comments.

The cost is usually as simple as expressing and typing out the model in our head as code. Languages that are famous for boilerplate, like Java, enforce this - and it makes writing Java slower, but can also make Java code quite explicit (I'm sure someone will respond talking about confusing Java code, that's not the point).

Reducing the cost of conveying context from writer to reader means we can convey more of that context in more places. That's a huge win, in my opinion, because I've personally found that so much implicit context gets lost over time, but it can be hard to always take the time to convey it.

Think about how many programs you've read with single character variable names, or no type annotations, or no comments. The more of that we can fix, the better, imo.

Tools like this do that. TabNine autocompletes full method type signatures for me in rust, meaning that the cost of actually writing out the types is gone. That's one less cost to pay for having clearer, faster code.

Re: GitHub Copilot

#465

Post by cunthorpe »

throwaway675309 wrote: post #454
inimino wrote: post #385

I'm amazed to see how positive the overall response is to this idea. Almost as if programmers think that writing programs is the worst part of the job and ready to be automated away. As someone more aligned with the Dijkstra perspective, this seems to me like one of the single worst ideas I've ever seen in this domain. We already have IDEs and other tools leading to an increase in boilerplate and the acceptance of it…

I mean you say this, but you and most likely the majority of programmers rely on dozens of repositories, packages and libraries with likely zero deep understanding of it (and at the very least haven't read the source code of ) so I don't really understand the difference here. The advantage of something like this is that instead of having to go to stack overflow or any number of reference sites and copy pasta it can j…

Importing an external, tested, reliable dependency is completely different from anonymous non-checked untested code in your repository committed by someone who did not even read it.

Check out the memoize example. That fails as soon as you pass anything non-primitive but there’s no one documenting that.

Re: GitHub Copilot

#466

Post by IncRnd »

npteljes wrote: post #190
natfriedman wrote: post #107

Earlier quoted context omitted.

It shouldn't do that, and we are taking steps to avoid reciting training data in the output: https://copilot.github.com/#faq-does-github-copilot-recite-c... https://docs.github.com/en/early-access/github/copilot/resea... In terms of the permissibility of training on public code, the jurisprudence here – broadly relied upon by the machine learning community – is that training ML models is fair use. We are certain this…

> ...the jurisprudence here – broadly relied upon by the machine learning community – is that training ML models is fair use. If you train az ML model on GPL code, and then make it output some code, would that not make the result a derivative of the GPL licensed inputs? But I guess this could be similar to musical composition. If the output doesn't resemble any of the inputs, or contains significant continous portion…

> If the output doesn't resemble any of the inputs, or contains significant continous portions of them, then it's not a derivative.

In this particular case, the output resembles the inputs, or there is no reason to use Github Copilot.

Re: GitHub Copilot

#468

Post by echelon »

throwaway675309 wrote: post #454
inimino wrote: post #385

I'm amazed to see how positive the overall response is to this idea. Almost as if programmers think that writing programs is the worst part of the job and ready to be automated away. As someone more aligned with the Dijkstra perspective, this seems to me like one of the single worst ideas I've ever seen in this domain. We already have IDEs and other tools leading to an increase in boilerplate and the acceptance of it…

I mean you say this, but you and most likely the majority of programmers rely on dozens of repositories, packages and libraries with likely zero deep understanding of it (and at the very least haven't read the source code of ) so I don't really understand the difference here. The advantage of something like this is that instead of having to go to stack overflow or any number of reference sites and copy pasta it can j…

I think as our field evolves, more work will be dealing with high level abstractions. There is a massive need for distributed systems design. Companies have big ambitions, but not enough labor to accomplish them.

There will still be plenty of low level systems programming work. The field is growing, not shrinking.

One impact this may have is that it may make tasks easier and more accessible, which could bring lots of new talent and could also apply downward force on wages. But the counter to that is that there is so much more work to be done.

I'm all for new tools.

Re: GitHub Copilot

#469

Post by IncRnd »

ec109685 wrote: post #187
kif wrote: post #132

Earlier quoted context omitted.

I visited https://copilot.github.com/ , and I don't know how to feel. Obviously it's a nice achievement, not gonna lie. But I have a feeling it will end up causing more work. e.g. the `averageRuntimeInSeconds` example, I had to spend a bit of time to see if it was actually correct. It has to be, since it's on the front page, but then I realized I'd need to spend time reviewing the AI's code. It's cool as a toy, but I…

It has the ability to generate unit tests as well, which will help cut down some on the verification side if you feed it enough cases.

If you question the veracity of the code that is produced, you have to question the usefulness of the unit test that is produced.

Re: GitHub Copilot

#470

Post by _fat_santa »

inimino wrote: post #385

I'm amazed to see how positive the overall response is to this idea. Almost as if programmers think that writing programs is the worst part of the job and ready to be automated away. As someone more aligned with the Dijkstra perspective, this seems to me like one of the single worst ideas I've ever seen in this domain. We already have IDEs and other tools leading to an increase in boilerplate and the acceptance of it…

The way I see it, the tool is only as good as the programmer using it. This tool will generate the individual code blocks for you, but you still have to understand how to put it all together to deliver a working app.

Sure there will be some codebases out there that are plastered together using this tool, but when it comes to delivering software that is well written, performant and maintainable over the course of several years, you're still going to need a lot of skilled engineers to pull that off.

Post reply on HN