Live data from Hacker News

GitHub Copilot available for JetBrains and Neovim

github.com

291–300 of 446 posts

Re: GitHub Copilot available for JetBrains and Neovim

#291
post #213

I’ve never understood the value proposition for Copilot. In terms of difficulty, writing code is maybe on average a two out of ten. On average, maintaining code you wrote recently is probably a three out of ten in terms of difficulty, and maintaining code somebody else wrote or code from a long time ago probably rises to around a five out of ten. Debugging misbehaving code is probably a seven out of ten or higher. Gi…

I feel like 10 years from now we will look at thread like this and laugh akin to 64kb being enough.

Exactly, I'm already laughing reading the comments here considering I've been using copilot for weeks and it's a game changer

Re: GitHub Copilot available for JetBrains and Neovim

#292
post #232
post #213

I’ve never understood the value proposition for Copilot. In terms of difficulty, writing code is maybe on average a two out of ten. On average, maintaining code you wrote recently is probably a three out of ten in terms of difficulty, and maintaining code somebody else wrote or code from a long time ago probably rises to around a five out of ten. Debugging misbehaving code is probably a seven out of ten or higher. Gi…

> value proposition for Copilot. now, instead of copying off stackoverflow, it's gonna be off copilot. It will enable a lot more people to code who otherwise would not. Whether this is a good outcome or not...

Your comment hides some truth! Imagine coding today without stackoverflow. Possible, but you'd lose so much time looking for simple answers.

Re: GitHub Copilot available for JetBrains and Neovim

#293
post #76

Copilot is crazy. The other day, I was writing a Python function that would call a Wikipedia API. I pulled from the internet an example of a GET request, and pasted it as a comment in my code. # sample call: https://en.wikipedia.org/w/api.php?action=query&format=json&list=geosearch&gscoord=37.7891838%7C-122.4033522&gsradius=10000&gslimit=100 Then I defined a variable, base_url = "https://en.wikipedia.org/w/api.php?"…

Yesterday I tried to convert the representation of a number into another representation/type in Rust:

    let coeff = BigUint::from_str(x).unwrap();
    let coeff: ::ScalarField as PrimeField>::BigInt =
        coeff.try_into().unwrap();
    let x: ::ScalarField = coeff.into();

I wrote that, then I wanted to move that code in a function so I wrote:

    fn string_int_to_field_el(s: &str)

copilot suggested the following one-liner that did exactly the same thing:

    fn string_int_to_field_el(s: &str) -> ::ScalarField {
        let x: ::ScalarField = s.parse().unwrap();
        x
    }
I still don't understand how some heuristics could produce this code. It's mind blowing.

Re: GitHub Copilot available for JetBrains and Neovim

#294

I have many thoughts about Copilot, but here are two. First, as much as I don't like the idea of Copilot, it seems to be good for boilerplate code. However, the fact that boilerplate code exists is not because of some natural limitation of code; it exists because our programming languages are subpar at making good abstractions. Here's an example: in Go, there is a lot of `if err == nil` error-handling boilerplate. Ru…

> This means that Google was careful to not make a large amount of copy-righted works publically accessible. Such is not the case for GitHub Copilot in particular Armin Ronacher’s tweet [19] The fast inverse square root algorithm referenced here didn't originate from Quake and is in hundreds of repositories - many with permissive licenses like WTFPL and many including the same comments. It's not really a large amount…

> The fast inverse square root algorithm referenced here didn't originate from Quake

Where did it come from then? And what license did the original have?

> and is in hundreds of repositories - many with permissive licenses like WTFPL and many including the same comments.

If the original was GPL or proprietary, then all of this copies with different licenses are violating the license of the original. Just because it exists everywhere does not mean Copilot can use it without violating the original license.

> It's not really a large amount of material, either.

No, but I would argue that it is enough for copyright because it is original.

> GitHub claims they haven't found any "recitations" that appeared fewer than 10 times in the training data.

Key word is "claim". We can test that claim. Or rather, you can, if you have access to Copilot, you can try the test I suggested at https://news.ycombinator.com/item?id=28018816 . Let me know the result. Even better, try it with:

    // Computes the index of them item.
    map_index(
because what's in that function is definitely copyrightable.

> With the exceptions mentioned above, what you get back from asking for more code won't just be more and more of a particular work. Realistically I think you'd be able to get significantly more from Google Books.

That can only be tested with time. Or with the test I gave above.

I think that with time, more and more examples will appear until it is clear that Copilot is a problem.

Nevertheless, a court somewhere (I think South Africa) recently ruled that an AI cannot be an inventor. If an AI cannot be an inventor, why can it hold copyright? And if it can't hold copyright, I argue it's infringing.

Again, only time will tell which of us is correct according to the courts, but I intend to demonstrate to them that I am.

Re: GitHub Copilot available for JetBrains and Neovim

#295

Earlier quoted context omitted.

Copilot also optimizes for speed to a degree. It's akin to advanced auto complete. IntelliJ auto-completion is great. As much as it pains to say this, I don't think I will be as effective writing Java in Vim as much as I am with IntelliJ. The key differentiator is the auto complete speed. Copilot I feel is just auto complete on steroids. It may not be perfect yet, but there is definitely a problem it solves.

Have you used it? My experience was quite atrocious. Copilot is not auto complete. It’s nonsense. I attempted to use it continuously for three weeks. I tried because I know someone who built it and I wanted to give them the benefit of the doubt. It never prompted me with any code that was useful. It only ever slowed me down and caused me frustration. It’s nothing like Intellisense. It’s just trash.

It's helped me out quite a bit.

When I'm writing Angular code, it often fills in the correct boilerplate code, and is especially helpful when writing unit tests. I'm also quite surprised when it autocomplete various filter functions.

It isn't perfect, but it's been helpful filling in the mundane, simple stuff.

Re: GitHub Copilot available for JetBrains and Neovim

#296
post #76

Copilot is crazy. The other day, I was writing a Python function that would call a Wikipedia API. I pulled from the internet an example of a GET request, and pasted it as a comment in my code. # sample call: https://en.wikipedia.org/w/api.php?action=query&format=json&list=geosearch&gscoord=37.7891838%7C-122.4033522&gsradius=10000&gslimit=100 Then I defined a variable, base_url = "https://en.wikipedia.org/w/api.php?"…

This comment is accidentally the perfect example of why copilot is a horrific idea.

The old "just copy-paste from Stack Overflow" approach to development is satirised and ridiculed these days (despite being still in common practice I'm certain), because as we all know so well by now, an accepted answer on SO does not always equate to a correct answer. Yes, the SO guys & community do do their best to improve answer quality iteratively (wiki answers, etc.), but there's still a lot of bad answers, and even many of the "good" ones become outdated or don't keep up with modern best-practice (especially when it comes to security).

Omitting urlencoding isn't the biggest crime, but it is a pretty standard URL-building step, and the fact that a tool released this year is spitting out code that omits something so simple is fairly damning. It's also a micro-example of much larger errors Copilot will surely be responsible for. Missing url encoding can be an injection vector in many applications, even if it's not the most common risk, but miss encoding in other string-building ops and you've made your way into the OWASP Top 10.

The big difference between copilot and SO is there's no community engaging in an open & transparent iterative process to improve the quality of answers.

Re: GitHub Copilot available for JetBrains and Neovim

#297
post #79

I tried it on IntelliJ recently. The examples I tested blew my mind. Yet, I think there are two things that need to improve to get me to use it regularly (it will get there!): - less than perfect import/types/var suggestions that LSP in typed languages would've made perfect suggestions for (e.g named import in go would use the package name instead). - latency feels a bit high and my thoughts would get interrupted wai…

> latency feels a bit high and my thoughts would get interrupted waiting for a suggestion to come. How high? That's interesting.

I haven't had problem with the latency personally

Re: GitHub Copilot available for JetBrains and Neovim

#298

Earlier quoted context omitted.

I'm not so confident this is really different from how a pro Go player would react 10 years ago to the analogous question. Put it this way: in 5 years will there be an AI that's better than 90% of unassisted working programmers at solving new leetcode-type coding interview questions posed in natural language? Arranging an actual bet is too annoying, but that development in that timeframe doesn't seem unlikely. It mig…

> I'm not so confident this is really different from how a pro Go player would react 10 years ago to the analogous question. Yes, and there were people in the 1960s who thought computers of the time were only a decade away from being smarter than humans. The question is one of category -- Go is something that a computer could conceivably be better than a human being at. There were certainly Go programs better than so…

You may be right.

A programmer's job bridges the informal and the formal. Previous automation practically always was about helping you work with the formal end. A tool that can bridge the informal and the formal on its own is new. That was my first point and most basically why I'm suspicious of dismissals. These developments don't have to 100% substitute for a current human programmer to change the economics of what talents are rewarded.

Re: GitHub Copilot available for JetBrains and Neovim

#299
post #289
post #213

I’ve never understood the value proposition for Copilot. In terms of difficulty, writing code is maybe on average a two out of ten. On average, maintaining code you wrote recently is probably a three out of ten in terms of difficulty, and maintaining code somebody else wrote or code from a long time ago probably rises to around a five out of ten. Debugging misbehaving code is probably a seven out of ten or higher. Gi…

Did you try it? Because I've been using it for weeks and it makes me read these types of comments as "I don't understand the value of the internet" or "what's the purpose of owning a phone". It's night and day if you have it enabled or not. There's just no question about the value proposition once you start using it. I mean, you can tell comments here from people who have actually been using it, and people who have n…

> Because I've been using it for weeks and it makes me read these types of comments as "I don't understand the value of the internet" or "what's the purpose of owning a phone".

And yet apart from making this very inaccurate comparison you haven't made any argument for why such a thing as Copilot would be useful to anyone. How do you personally find Copilot useful? And why do you think someone whose job demands more than copy/pasting boilerplate code should try Copilot? The onus is on you to convince the skeptics.

Re: GitHub Copilot available for JetBrains and Neovim

#300
Copilot thread is always hot. TBH I don't mind the plagiarism. They can use my code.

The real problem is indeed the code quality, since Copilot does actively provide low-quality codes, and this will bite a lot of people. I guarantee. I don't think this massive learning approach can't be the solution. We need an extra kick.

My shower-thought solution for this garbage-spewing problem is to design a new library with Copilot in mind. Tighten up the interface, and use strict patterns instead of domain-specific hacks.

In other words, we can make libraries so lame that Copilot (and newb programmers) simply can't produce low-quality code. Just disregard smart programmers with fast hands. They don't need any help anyway. Don't even try to target them, because it's gonna cause more stupid flame wars...

Post reply on HN