Live data from Hacker News

GitHub Copilot

copilot.github.com

471–480 of 1001 posts

Re: GitHub Copilot

#471

Earlier quoted context omitted.

We think that software development is entering its third wave of productivity change. The first was the creation of tools like compilers, debuggers, garbage collectors, and languages that made developers more productive. The second was open source where a global community of developers came together to build on each other's work. The third revolution will be the use of AI in coding. The problems we spend our days sol…

I appreciate this insight, as a proponent of progress studies. It is indeed a pragmatic view of what the industry will be or should be. I believe the thing that would be also appreciated would be a pair security auditor. Most vulnerabilities in software can be avoided early on in development , I believe this could be a great addition to Github's Security Lab securitylab.github.com/

Do you or 'natfriedman have authored any works in a public repository, so that we can judge the validity of the pragmatic view?

Re: GitHub Copilot

#472

Earlier quoted context omitted.

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.

I think I'd love to use this to generate tests and then write the functions myself. Test generation seems like a killer feature.

Yes!! Totally agree. Imagine writing a method and then telling an AI to write your unit tests for it. The AI would likely be able to come up with the edge cases and such that you would not normally take the time to write.

While I think the AI generating your mainline code is interesting, I must certainly agree that generating test code would be the killer feature. I would like to see this showcased a little more on the copilot page.

Re: GitHub Copilot

#473

Earlier quoted context omitted.

Pack it all up, boys, programming's over. Hello, AI. Anyone want to hire me to teach your grandma how to use the internet?

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 just don't believe it. Having experienced terrible cheap outsourced support and things like Microsoft's troubleshooting assistant (also terrible), I'm willing to pay for quality human professionals. They have a long way to go before I change my mind.

Re: GitHub Copilot

#475

Earlier quoted context omitted.

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

I think this goes beyond one project. In your lifetime you just have to write certain things again and again and then you have to write the abstractions again and again.

Maybe that warrants a library, but then you also have to hook that up with the ever so slightly different boilerplate code.

If this 90% of the easy stuff is done for you, that gives you more time to focus on the 10% that matter.

Re: GitHub Copilot

#476
I wonder if this kind of technology can push industry into more advanced languages. If a programmer can restrain the space of available programs more, it should aid the tool to give even better results.

Re: GitHub Copilot

#477

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…

Not looking forward to dealing with this from a security point of view. It's difficult to get developers to accept responsibility for security vulnerabilities in libraries they've selected for their project ("That's not my code!"). I can see the same thing happening with generated code where they don't want to take responsibility for finding a way to remediate any vulnerabilities they didn't personally type in. Of course those who exploit the vulnerabilities won't care how it got into the code. They're just happy they're able to make use of it.

Re: GitHub Copilot

#478
I think this would be a great resource for beginners particularly. It helps give them the code that will work for them and they can understand what it's returning. That was my biggest issue when I first started with REST calls was not knowing what to use and why things were being used on the server side. Eventually it started to click for me, but I had a lead guide me. In particular we worked with SharePoint which I had no idea had it's own API at the time which added to the complexity. Overall I think the "See different examples" is going to be the best feature out of all of them.

Re: GitHub Copilot

#479

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…

Next step will be AI to approve the code, because. if someone is producing 5k LOC a day there are people who need to read & approve this code...

Re: GitHub Copilot

#480

Earlier quoted context omitted.

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.

> anonymous non-checked untested code

What? It's not anonymous, it's still committed by a dev. It can be non-checked and untested, that's true. But it's not any less untested than any other code. If you choose not to write tests for your code, this won't change anything.

The only issue I see with this is it being potentially unchecked. And the solution to that is reading all the code you commit, even though it's generated by AI.

Post reply on HN