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

431–440 of 1001 posts

Re: GitHub Copilot

#431

Post by augustk »

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…

Indeed, using tools to manage complexity tends to make the complexity acceptable and leads to more complexity.

Re: GitHub Copilot

#432

Post by iwintermute »

wpietri wrote: post #381

Does this solve the right problem? Getting some code on the page has rarely been the expensive part of building something. Indeed, some long-ago experience with code generators suggests that making it easy to create code makes many problems worse down the line.

It's solving 'mechanical' problem. The optimistic twist on this helper is that it just raises the bar - human programmer should better be more useful than 'brainless' code generator - meaning not only being able to write a loop or solve leetcode task, but also understand context and what he's trying to solve for.

As you say typing code is not a bottleneck for problem solving

Re: GitHub Copilot

#433

Post by s_dev »

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…

Coding is inherently difficult -- any tools even as basic as color highlighting/spell checking massively help understanding code in front of you. There isn't a hope this can replace any programmers but instead aid their workflow. I great example is simply refactoring code with SOLID after building a feature or fixing a bug -- a lot of this can be easily automated. Having a machine suggest and a human accept is a worthy trade off. Another similar example is the Google bot that presents search suggestions for you.

I don't think your concerns are well grounded.

Re: GitHub Copilot

#434

Post by dgb23 »

pnt12 wrote: post #294
dgb23 wrote: post #188

Earlier quoted context omitted.

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 simil…

Couldn't disagree more: Smart programmers are are not coding thousands of lines of code every day. There's so much more to in software engineering other than coding, that's why senior engineers spend less time writing code than juniors. If a slow typer is using a auto-completer, he's not learning to type faster. If auto complete fails, then the slow programmer will need to invalidate the code first, and then type it…

Maybe I reacted optimistically because your objections are reasonable and relatable. But I‘m still very interested in how this will actually play out. I want to see and feel it in action.

Re: GitHub Copilot

#435

Post by bluetwo »

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…

All I can think of is how many times I've grabbed a code example from StackOverflow only to discover it had some obvious bug in it. The answer is many, many times.

Re: GitHub Copilot

#436

Post by grumple »

fzaninotto wrote: post #64
fabiospampinato wrote: post #53

Earlier quoted context omitted.

How big/complicated are the functions Copilot is autocompleting for you? I'm thinking perhaps reading 10 potential candidates is actually slower and less instructive than trying to write the thing yourself.

It shows the suggestions line by line, and only shows the best guess. It's not more intrusive than Intellisense. You can actually see all the code blocks Copilot is thinking about if you want to, but that is indeed a distraction.

Even snippets are so bad I have to turn them off. I can't even fathom how bad the suggestions are going to be for full blocks of code. But I guess I'll see soon...

Re: GitHub Copilot

#437

Post by staticassertion »

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…

> 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 things - code that's easier to read and analyze, but takes longer to write. IDEs and tools like this cut the cost of writing, giving us easier to read code and easier to analyze code for free.

IDEs have supported templates forever. I never write out a full unit test, I type `tmod` and `tfn` and then fill in the blanks. This is basically the same thing to me.

> Folks that still expect you to only check in code you understand and can explain will become a minority.

This isn't true at all. Having used TabNine I don't have it write code for me, it just autocompletes code that's already in my head, give or take some symbol names maybe being different.

All this is is a fancy autocomplete with a really cool demo.

Re: GitHub Copilot

#438

Post by nyghtly »

wpietri wrote: post #381

Does this solve the right problem? Getting some code on the page has rarely been the expensive part of building something. Indeed, some long-ago experience with code generators suggests that making it easy to create code makes many problems worse down the line.

This is a very good point.

Re: GitHub Copilot

#440

Post by jonas_kgomo »

natfriedman wrote: post #143
jonas_kgomo wrote: post #93

Earlier quoted context omitted.

This is obviously controversial, since we are thinking about how this could displace a large portion of developers. How do you see Copilot being more augmentative than disruptive to the developer ecosystem? Also, how you see it different from regular code completion tools like tabnine.

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/
Post reply on HN