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

GitHub Copilot available for JetBrains and Neovim

github.com

Post reply on HN
Print view View original

221–230 of 446 posts

Re: GitHub Copilot available for JetBrains and Neovim

#221

Post by boredtofears »

sillysaurusx wrote: post #172
c7DJTLrn wrote: post #112

Earlier quoted context omitted.

Bit of a dodgy way to form query parameters though. Other than for a quick script.

Speaking as a former pentester, this is a fine way to form query params in this specific case, if lat and long are floats. They're the only data you can control, and unless they're strings, it's useless for exploitation. Even denormal floats / INF / NAN won't help achieve an objective. I broadly agree with you, but people are pummeling Copilot for writing code that I saw hundreds of times. Yes, sometimes I was able t…

If the example code is everything that Copilot generated, there's no guarantee that lat or long are floats and that seems to be an implementation detail left to the user.

Isn't that a pretty big risk though? Specifically, that people will use co-pilot recommendations "as-is" and give little thought to the actual workings of the recommendation?

After all, if you have to intimately understand the code it's recommending are you really saving that much time over vetting a Googled solution yourself?

Re: GitHub Copilot available for JetBrains and Neovim

#222

Post by thamer »

e0a74c wrote: post #202
Matthias1 wrote: post #150

Earlier quoted context omitted.

I'm not against "copying" code. I just looked up "python build url query" The first link describes the `urllib.parse. urlencode` function which takes a dict. So I would build the query like so: from urllib.parse import urlencode urlencode({ "action": "query", "format": "json", ... "gscoord": f"{str(latitude.value)}|{str(longitude.value)}", }) I think this is orders of magnitude clearer code. But that's a parameter th…

I'm surprised no one has suggested using `requests` considering how easy, safe and readable it is: >>> import requests, pprint >>> >>> >>> url = "https://en.wikipedia.org/w/api.php" >>> resp = requests.get( ... url, ... params=dict( ... action="query", ... list="geosearch", ... format="json", ... gsradius=10000, ... gscoord=f"{latitude.value}|{longitude.value}" ... ) ... ) >>> >>> pprint.pprint(resp.json()) {'batchco…

For what it's worth, Copilot can do it.

I typed the following prompt:

    def search_wikipedia(lat, lon):
        """
        use "requests" to do a geosearch on Wikipedia and pretty-print the resulting JSON
        """
And it completed it with:

    r = requests.get('https://en.wikipedia.org/w/api.php?action=query&list=geosearch&gsradius=10000&gscoord={0}|{1}&gslimit=20&format=json'.format(lat, lon))
    pprint.pprint(r.json())

Re: GitHub Copilot available for JetBrains and Neovim

#223

Post by NumberWangMan »

matsemann wrote: post #122
drran wrote: post #118

Earlier quoted context omitted.

> The tests doesn't actually test functionality, edge cases etc, just that things doesn't crash in a happy-path. This is low coverage. > Any changes to an implementation breaks a test needlessly, because the test tests specifics of the implementation, not correctness. This is bad design. > In codebases for dynamic languages, most of what these tests end up catching is stuff a compiler would catch in a statically type…

> This is low coverage. No, as a sibling comment to mine shows, it's actually easy to make 100% coverage with bad tests, since one doesn't challenge the implementation to handle edge cases.

I think maybe you are using different definitions of coverage -- textual coverage vs logic coverage.

Re: GitHub Copilot available for JetBrains and Neovim

#224

Post by thrashh »

sillysaurusx wrote: post #172
c7DJTLrn wrote: post #112

Earlier quoted context omitted.

Bit of a dodgy way to form query parameters though. Other than for a quick script.

Speaking as a former pentester, this is a fine way to form query params in this specific case, if lat and long are floats. They're the only data you can control, and unless they're strings, it's useless for exploitation. Even denormal floats / INF / NAN won't help achieve an objective. I broadly agree with you, but people are pummeling Copilot for writing code that I saw hundreds of times. Yes, sometimes I was able t…

But I would still never not escape the params because you don’t know how that code will change one day or where it will end up, and chances are that you won’t remember to fix it later if you don’t fix it now.

We just had a major failure at work recently because someone decided to not decode URL params and their code worked fine for years because it never mattered… until it did.

Just do it right. It’s so easy. Why risk yourself a ton of headache in the future to save you a few seconds?

Re: GitHub Copilot available for JetBrains and Neovim

#225

Post by odonnellryan »

thamer wrote: post #222
e0a74c wrote: post #202

Earlier quoted context omitted.

I'm surprised no one has suggested using `requests` considering how easy, safe and readable it is: >>> import requests, pprint >>> >>> >>> url = "https://en.wikipedia.org/w/api.php" >>> resp = requests.get( ... url, ... params=dict( ... action="query", ... list="geosearch", ... format="json", ... gsradius=10000, ... gscoord=f"{latitude.value}|{longitude.value}" ... ) ... ) >>> >>> pprint.pprint(resp.json()) {'batchco…

For what it's worth, Copilot can do it. I typed the following prompt: def search_wikipedia(lat, lon): """ use "requests" to do a geosearch on Wikipedia and pretty-print the resulting JSON """ And it completed it with: r = requests.get('https://en.wikipedia.org/w/api.php?action=query&list=geosearch&gsradius=10000&gscoord={0}|{1}&gslimit=20&format=json'.format(lat, lon)) pprint.pprint(r.json())

That doesn't exactly do what the guy above you was talking about, though.

Re: GitHub Copilot available for JetBrains and Neovim

#226

Post by tikhonj »

Graffur wrote: post #56
manquer wrote: post #29

Earlier quoted context omitted.

Writing tests for the sake of coverage is already practically useless which is what a lot of orgs do, This could maybe generate such tests. However it doesn't materially impact quality now, so not much difference if automated. One of the main value props for writing meaningful unit tests, is it helps the developer think differently about the code he is writing tests for, and that improves quality of the code composit…

Why is that useless? Codebases I have worked on that had high code coverage requirements had very little bugs. * It promotes actually looking at the code before considering it done * It promotes refactoring * It helps to prevent breaking changes for stuff that wasn't supposed to change

I saw a cool study recently (summarized well here[1]) with an empirical experiment on how well code coverage predicts how well a test suite catches bugs. They found that the number of test cases correlated well with the test suite's effectiveness, but, when controlling for the number of tests, code coverage didn't.

It was a pretty thorough study:

> Our study is the largest to date in the literature: we generated 31,000 test suites for five systems consisting of up to 724,000 lines of source code. We measured the statement coverage, decision coverage, and modified condition coverage of these suites and used mutation testing to evaluate their fault detection effectiveness. We found that there is a low to moderate correlation between coverage and effectiveness when the number of test cases in the suite is controlled for.

Given their data, their conclusion seems pretty plausible:

> Our results suggest that coverage, while useful for identifying under-tested parts of a program, should not be used as a quality target because it is not a good indicator of test suite effectiveness.

That's certainly how I approach testing: I value having a thorough test suite, but I do not treat coverage as a target or use it as a requirement for other people working on the same project.

[1]: https://neverworkintheory.org/2021/09/24/coverage-is-not-str...

Re: GitHub Copilot available for JetBrains and Neovim

#227

Post by odonnellryan »

snicker7 wrote: post #197
lambdaba wrote: post #173

Earlier quoted context omitted.

This. Code should be optimized for reading, I think this kind of code is OK for exploratory stuff, but needs to be rewritten later.

Well. Code should be optimized first for correctness, and simple string concatenation will not work for URL params.

It'll certainly work, just seems sloppy.

Re: GitHub Copilot available for JetBrains and Neovim

#228

Post by [deleted] »

ctoth wrote: post #216
pugets wrote: 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?"…

The next version of Copilot will submit its answers to HN and return the highest-voted comment that compiles, after stripping out the well actually spurious tokens. Just look how well it worked this time?

[deleted]

Re: GitHub Copilot available for JetBrains and Neovim

#229

Post by drran »

matsemann wrote: post #122
drran wrote: post #118

Earlier quoted context omitted.

> The tests doesn't actually test functionality, edge cases etc, just that things doesn't crash in a happy-path. This is low coverage. > Any changes to an implementation breaks a test needlessly, because the test tests specifics of the implementation, not correctness. This is bad design. > In codebases for dynamic languages, most of what these tests end up catching is stuff a compiler would catch in a statically type…

> This is low coverage. No, as a sibling comment to mine shows, it's actually easy to make 100% coverage with bad tests, since one doesn't challenge the implementation to handle edge cases.

It's easy to achieve 100% coverage with happy-path code and low quality shallow tests, agreed.

AFAIK, «high coverage» may have different meaning for different people. For me, it's «high quality», for others it's «high percentage», e.g. «full coverage» or «80% coverage», which is easy to OKR.

Re: GitHub Copilot available for JetBrains and Neovim

#230

Post by deckard1 »

mewse wrote: 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 don't see it either. The context switch between being in the zone/flow and writing the exact code I'm thinking of to suddenly reviewing blocks of foreign and quite possibly wrong code seems like a net negative value proposition. I can't even get autocorrect on my phone to do the right thing half the time.

Writing code is easy. Architecture, refactoring, and solving business problems are the hard parts of the job.

Writing new code is also generally the most rewarding aspect of the job. Co-pilot promises to turn that into just another unrewarding chore, like slinging 3rd party libraries together.

Post reply on HN