up = foo.north()
right =
and then it will correctly suggest up = foo.north()
right = foo.east()
down = foo.south()
left = foo.west()
This requires a kind of linguistic understanding that is beyond basic intellisense. If you are just wanting it for basic intellisense autocomplete, it's not much better than JetBrains stuff. But for things that require linguistic comprehension, it's incredibly useful.For example, if I have a `Point` object with `x` and `y` fields, and I make a function called `lowest_point`, it knows I want to the point with the minimum `y` value. Because it knows the name `y` is most typically used for vertical direction, and the word `lowest` also implies vertical direction. This is kind of a linguistic/semantic knowledge that is not found in just the type system.
1. The surrounding code
2. The type/intellisense information of all the identifiers in the surrounding code
3. The class/function definition of any identifiers in the surrounding code
I think #3 will be huge. There is a huge difference in Copilot's performance when dealing with types defined right above where you are writing code, and types defined in some far-away module or library. Right now if you use a class you defined in another file or adjacent project, Copilot can't see it. But your IDE has jump-to-definition functionality that could trivially be wired in to something like Copilot.
The team behind Stable Diffusion (the image synthesis model that's been all over HN recently) have said they are working on stuff like Copilot as well, so I expect we will see a huge transformation in this space in the next year or two.
It feels like something that is obvious and should go in the copilot plugin rather than copilot itself.
Given N suggestions, validate the code + snippet on them using normal error checking.
Promote suggestions with no errors.
The intellij plugin, for example, will often suggest 'default' suggestions that are entirely wrong. Given that `foo.bar.foobar()` exists, it'll suggestion `foo.something.SomethingClever()` when those functions don't exist, or exist on types other than foo.
However, if you look at all the suggestions on the side panel, you'll see several of them are actually valid. It's just that the default completion isn't.
It feels like magic because it really does get some things right.
But I find that in most cases, because it's often wrong, you have to deal with wrong suggestions, and be very careful about what you accept.
I feel that for most coding scenarios, it doesn't actually, in most cases, do that much but save a few strokes.
I suggest that if there is 'high boilerplate' - then maybe there's upside.
But for most things, it really doesn't help, despite how in some cases it's really magical.
I turned it off and don't miss it.
What I would however prefer is merely 'much better autocomplete'.
Somewhere between 'ok autocomplete' and 'code suggestions' is the sweet spot for dev. that's not boilerplate.
At a worst it provides a great starting point to jump off from, at best it writes it for me just like I would have (matching style/variable naming/etc).
/*
<http request here>
The well-type class representation of this is:
*/
And then it spits out a totally sane and reasonable class. In this file I already have 10+ classes already defined and manually touched up by me to rename some things, remove some fields, etc. So every time I add a new one, Copilot takes into account the previous examples and each addition requires less or no manual tweaking.Unless, as in many systems, y=0 is the top and y increases downward.
For example, I just gave Copilot:
# The screen is inverted, so bigger y values are lower
def lowest_point(points):
and it completed: # The screen is inverted, so bigger y values are lower
def lowest_point(points):
lowest = points[0]
for point in points:
if point.y > lowest.y:
lowest = point
return lowest
Even if you write some code that implies that bigger y is lower, Copilot will pick up on it.Are you sure? If you would look at the statistics what comes after
up = foo.north()
right =
I bet most of the time it's up = foo.north()
right = foo.east()
down = foo.south()
left = foo.west()But it does a really good job, and it's not just matching code it's seen before. You can use any variable name. You can do this in a weird programming language which uses weird symbols for assignment and calls. copilot will probably see though it and give you a good prediction.
You can probably even swap west for not_east in code elsewhere in the file, and it will manage to predict that you also want not_east here. And I guaranteed nobody has written code like that before.
up = foo.north()
right = foo.east()
down = foo.south()
And you won't notice?> We need the legal right to do things like host Your Content, publish it, and share it. You grant us and our legal successors the right to store, archive, parse, and display Your Content, and make incidental copies, as necessary to provide the Service, including improving the Service over time. This license includes the right to do things like copy it to our database and make backups; show it to you and other users; parse it into a search index or otherwise analyze it on our servers; share it with other users; and perform it, in case Your Content is something like music or video.
But, maybe not, because humans liked the outputs enough to share them and put them on the Internet, so maybe they don't have much of an effect quite yet.
How is GHC breaking this license?
>You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice
Legally, not stealing. Ethically? I’d call that stealing.
OK ... interesting choice. This could mean almost anything. I can "write a web server" in a python 1-liner in about 2 seconds (ctrl-r SimpleHttpServer, enter).
https://github.com/hofstadter-io/demos/tree/main/full-stack-...
I've since shortened that demo to be even faster for a user to complete
the hard bit of being a developer is deciding in precise, pedantic, utterly exact detail on what needs building to solve the business problem
not bashing out the code in the editor
now if they had given out a vague problem that ended up with the dev eventually producing a webserver in Javascript, then fine
but then the difference copilot makes would be a much smaller percentage of the development effort
I swear we're going back to the age of "lines of code written per hour", just now with arTiFiCiAL InTellIgEncE
The process seemed to involve have a test suite to write against. So, essentially, you had some/most of your "business problem" defined by acceptance tests (produce these outputs given these inputs). Some of that process may normally stretch out for days or weeks during meetings - condensed down, provided for you ahead of time takes some of that variability out.
I was possibly a bit more surprised that less than 80% finished. Did they not commit code? Did they submit code but it didn't pass? Did they take too long? Was the 'did not finish' an explicit call on the dev side ("I'm done") or did they just stop taking input after X days?
I found copilot to be nothing but a hinderance and additional cognitive load. Not only do you need to think about the code you want, you need to review the (usually wrong) code copilot produces and either reject it or edit it to make it right. This is a lot more mental overhead than just writing the code.
Moreover writing boilerplate is rarely my daily activity, when it is, it's faster to copy paste from a similar file.
On the other hand, few exceptional devs I know, the kind of rockstar 10x engineer, insanely productive and very smart about product and business, not just great coders, people that were leads in faang 15 years ago already and are responsible for high impact quality sooftware, speak very highly of it and how better it makes them, which crushes my doubts about copilot.
Beyond basic algorithms and boilerplate code completion (which would arguably be better implemented via better intellisense than ML), it was basically zero help.
Even in the areas it helped, time to eval mostly equaled the time I would have taken to write the same thing manually.
[0]: https://docs.microsoft.com/en-us/visualstudio/intellicode/ov...
> [...] The GitHub Copilot extension sends your comments and code to the GitHub Copilot service, and it relies on context, as described in Privacy below - i.e., file content both in the file you are editing, as well as neighboring or related files within a project. It may also collect the URLs of repositories or file paths to identify relevant context. The comments and code along with context are then used by OpenAI Codex to synthesize and suggest individual lines and whole functions.
- from https://github.com/features/copilot/#faq - see "How does GitHub Copilot work?"
if (myTypedVar === "" <--
Back off Copilot, let TypeScript Intellisense give me the correct suggestions. Or at least run the Copilot suggestions through TS first and make sure it doesn't suggest type errors.
Running through the type-checker is an interesting idea - even if you didn’t reject suggestions outright (which seems like it could frequently reject suggestions you actually wanted) it may be a useful weighting function.
Similarly, running through eslint (or whatever linting system is appropriate) to avoid introducing obvious fixable formatting errors, like incorrect quotes, would be wonderful.
The neovim integration worked very well, at least when I used it with Clojure and associated tooling. Could move seamlessly between what my Clojure tooling provides me with, and what Copilot did.
Cognitive load is massively decreased, I don't have to push much on the working memory stack to do small utility functions, they just write themselves now (especially if I write the type signature first). I can spend a lot more of my time at the middle level of abstraction, and keep moving.
This is contrived, but in general (programmer + fuzzy memory + computer suggestion) means there's a possibility for it to be wrong, and you have to rely on the type system and reviewing it carefully to make sure there wasn't a mistake.
Privacy concerns due to copilot makes it unusable for companies with closed source code.
I’m hoping that eventually there will be a stable diffusion level solution in this field.
However, every now and then, there came a typed object or something mundane and Copilot exceled at it, so I decided that I want to find a way for it to coexist in a way that's as easy to use as pressing Tab to expand it. Lo and behold - I found an unused key below Tab (AKA caps lock), remapped it and now it doesn't get in the way and I can use Copilot's help only when I want.
Seems like popularizing snippets wouldve gone further but then you miss out on the buzzwords.
First off, I don't see a link to the "HTTP server in JavaScript" task. It's really hard for me to place much faith in their conclusions when it's not even clear what the problem definition was.
Second, I believe that a lot of more senior developers and development managers who take secure development practices somewhat seriously will not be able or willing to use Copilot in any sort of proprietary setting. Here is a quote from the Copilot FAQ:
> [...] The GitHub Copilot extension sends your comments and code to the GitHub Copilot service, and it relies on context, as described in Privacy below - i.e., file content both in the file you are editing, as well as neighboring or related files within a project. It may also collect the URLs of repositories or file paths to identify relevant context. The comments and code along with context are then used by OpenAI Codex to synthesize and suggest individual lines and whole functions.
- from https://github.com/features/copilot/#faq - see "How does GitHub Copilot work?"
I believe this makes it simply a nonstarter in a lot of environments. I am wondering if there are a number of places that have restrictions on sharing their code with a third-party but don't know or don't care and so end up using Copilot anyway. I believe that short-sighted thinking like this is more prevalent in shops that have low-quality code, and I believe that the higher-quality the code, the less likely someone is to use Copilot, simply for the "I can't share my code, even if I use the most restrictive no-telemetry settings" reason. Give me a self-hosted Copilot, and I may try it out in anger.
Finally, I based some of my thinking on a recent Reddit /r/programming discussion of Copilot: https://old.reddit.com/r/programming/comments/wsnend/since_g...
After reading those posts, and internalizing them with my own view of coding, I believe Copilot is not ready for my personal use. Again: licensing considerations aside (if you actually can feel comfortable putting them aside, see NoraCodes comment in this HN thread e.g.), it is simply a non-starter for anything proprietary in nature. I am also of the mind that any code that is of necessity very tedious to write is in dire need of real attention, most likely in the form of tests and quite possibly refactoring to reduce the boilerplate if at all possible. I believe in the value of linters and automated code analysis tools and in continuous integration that runs after every commit. Give me a self-hosted Copilot, and we'll have a real chance to see how it works out - until then it's not going to be a boon to programmers.
- https://pvs-studio.com/en/blog/posts/ - I don't code in C or C++ but I love to read these posts with the limited understanding that I possess
- GitHub has another product which is good https://github.com/dependabot - similar in nature to Snyk, Renovate, etc.
- there was an HN thread yesterday about govulncheck which looks pretty nice as a Go-known-vulnerability-in-your-dependencies checker
- code review is invaluable
- continuous integration and a build that passes and expands to cover new bug cases is really helpful
When you're using it on a code base that it's familiar with, it'll often suggestion quality of life suggestions that you may not know about.
For example, using unity, did you know
Mathf.RoundToInt
Was a thing?I didn't, until I was using a normal way of doing it (eg. `(int) Math.Round(v);` and copilot popped this suggestion up.
I had similar experiences using opencv in python.
Maybe the suggestions aren't always perfect, but what it does do, is show you how other people have written code using the same engine/plugin/library you're using; and when you're learning a new API, that's extremely valuable.
The alternative (finding github projects using library X, browsing through the code) lets you do the same thing too, but its much much slower to pickup the same 'tips' about an API that way.
Specifically with regard to "give people a new task they haven't done before in language X with/without copilot", this kind of 'tip' for using an unfamiliar API seems high plausible for getting developers up to speed.
I wish it had support for doing this in a way that was 'favour suggestions like existing code base' to help on-board new developers.
That would be really really useful.
What would be great would be for an enterprise pricing capability, we would love to purchase this on behalf of our employees via a single interface.
A bunch of insecure clowns that somehow manage to feel personally threatened by a productivity tool. It's hilarious. Get over yourselves.
Copilot is just an intelligent, context-aware search engine that is plugged directly into your code editing workflow. It's nothing more. It's the sci-fi version of having a hardcoded `site:stackoverflow.com` google search box right next to your editor.
It's easily the nicest thing I've installed for productivity in a while, and it regularly amazes me what it can pick up from context. I can switch between code written in two different languages that is related, and copilot will often pick up enough context to give me correct suggestions in one language based on the code I just wrote in the other.
I found it most helpful in setting up boilerplate in when writing tests. It could offer testing some edge cases before I could think of them.