The thing I find really good is it can predict what I will do next. Say if I have a list of columns in some text somewhere in the project when I write one “df = df.withColumn(“OneItemInList”)”
Copilot will then add the same for all the other items - is really nice
I'm a bit scared for what this means as I don't think being able to faster write boilerplate is something worthwhile. The example ed_elliott_asc made is one of those examples where instead of fixing things so you don't have to repeat yourself, copilot makes it easy to just live with the boilerplate instead.
It's very good at translating between programming languages, including pseudocode.
It can write a lot more valid code much quicker than any human, and in a whole slew of languages.
I haven't had the urge to use it much after playing around with it constantly for a few days, but it was pretty mind-blowing.
More verbose languages like C++ become less obnoxious to write in. I know RSI has been mentioned and any tool which cuts down on excessive typing will help with that.
It sometimes reveals bits of the standard library I wasn't aware of in unfamiliar languages. I can write my intent as a comment and then it may pull out a one-liner to replace what I would have normally done using a for loop.
The main downside I've observed is that if I'm not trying to reign it in, it can result in a lot of WET code since it can pattern match other areas of the surrounding code but can't actually rewrite anything that has already been written. It is important to go back and refactor the stuff it produces to avoid this.
For example, I didn't know about self.fail() in unittests and had never used it, but Copilot suggested it and it produced the most readable version of the unit test
So not only would you have to submit a insanely large amount of code but you're also racing against literally millions of users writing legitimate code at any period of time.
But do you believe people being slower at writing boilerplate is undesirable?
If I want to throw an exception if an object is null or undefined, Co-pilot will do the if and the exception throw using the right error class, and a more meaningful error message that what I usually came up with.
If want to map some random technical data table to something useful in my programming language, I can copy paste the data from the documentation in pdf or html into a comment block, give an example, and co-pilot will write everything in the format I want.
If I want to slightly refactor some code, I can do it once or twice and co-pilot can help me a lot to refactor the remaining.
If I want to have a quick http server in nodejs, I don't have to Google anything.
It's a lot of tiny things like this.
https://twitter.com/ridiculous_fish/status/14527512360594513...
I was able to write {"Settings":...} and Copilot completed with {"Settings": "Configurações"} that tool is simply amazing.
I mean, it's sort of a false dichotomy -- it's omitting a "default speed" for writing boilerplate that is neither enhanced nor impeded.
the potential issue with an enhanced speed for writing boilerplate is that it means that there'll just be more and more boilerplate to maintain over time, and it's not clear what that cost over time will be.
How much more effort will be expended to replace things in multiple places? It exacerbates existing issues of "these two things look almost the same, but someone manually modified one copy...should that change be propagated?"
Meaning, it's essentially an ad-hoc code generator. Code generation can be a very useful technique (see protobufs), but without the ability to re-generate from a source?
Perhaps a possible enhancement might be for copilot to keep track of all blurbs it generated and propose refactoring/modifying all copies?
In a perfect world we’d all have excellent comprehensive metaprogramming facilities in our programming languages and no incidence of RSI (e.g. carpal tunnel syndrome). Code completion is a good tool to deal with these realities.
Also if your don't fully understand your code( when generated or copied from SO) as not uncommon with junior developers and data science practitioners, then they struggle to make even small change for the next iteration, because they don't fully understand what their code is doing and how.
When your code is composable or modifiable easily then iterations become faster because you understand what you have written. One of the reasons why analysts prefer Excel if data size is within limits.
So for example I was working with processing an image to extract features and a few variants of docstrings for the method got me a pretty close to working function which converted the image to gray scale, detected edges, and computed the result I wanted.
The helpful thing here was that there were certain APIs that were useful as a part of doing this that it knew but which I would have to do look up. I had to go through and modify the proposed solution: it got the conditional in the right place, but I wanted a broader classification so switched from a (255, 255, 255) check to a nearBlack(pixel) function which it then autocompleted successfully. I also had to modify the cropping.
When doing a similar task in the past I spent a lot more time on it, because I went down a route in which I was doing color classification based on the k nearest neighbors. Later I found that the AI I was working on was learning to exploit the opacity of the section of the screen I was extracting a feature from in order to maximize its reward, because it kept finding edge cases in the color classifier. I ended up switching to a different color space to make color difference distance functions more meaningful, but it wasn't good enough to beat the RL agent that was trying to exploit mistakes in the classifier.
Anyway, what I'm getting at here is that it is pretty easy to spend a lot of time doing similar things to what I'm doing and not get a great solution at the end. In this case though it only took a few minutes to get a working solution. CoPilot didn't code the solution for me, but it helped me get the coding done faster because it knew the APIs and the basic structure of what I needed to do. To be clear, its solutions were all broken in a ton of ways, but it didn't matter it still saved me time.
To give another example let's say you have a keyboard key event press and you weren't sure about how to translate that into the key that was pressed. key.char? key.key? str(key)? key.symbol? A former method of figuring out what the right key might be is looking up the code, but with CoPilot you type '# Get the key associated with the key press' then hit tab and it gives you code that is broken but looks perfect and you gain a false sense of confidence that you actually know the API. You later realize after being amazed that it knew the API so well that you didn't have to look it up that actually the key press event handles symbols differently and so it errors on anything that is used as a modifier key.
My general impression is something like: Wow, this is amazing. It understood exactly what I wanted and it knew the APIs and coded up the solution... Wait, no. Hold on a second. This and that are wrong.
Boilerplate generally exists for a reason, and it's not because the creator likes typing.
In the test body, I wrote "foo" to the socket. Copilot immediately filled in the rest of the test: read from the socket, check that the result is "Hello, foo", and fail the test with a descriptive error otherwise.
wtf? How did it figure out that the correct result was "Hello, foo"? I changed "Hello" to "Flarbnax", and sure enough, Copilot suggested "Flarbnax, foo". I added a "!" to the end, and it suggested that too. After pushing a bit further, the suggestions started to lose accuracy: it would check for "???" instead of "??" for example, or it would check for a newline where there was none. But overall I came away very impressed.
So how about an already poisoned well. How up to date is the average Github project on encryption standards?
It‘s useful enough for me, as a magic autocomplete.
Really the thing is there's not way to ascribe correctness to a piece of code right, like humans fail at this even. The only "correct" code is like rote algorithmic code that has a well defined method of operation. And there's likely a lot more correct examples of that, like way more than you'd ever be able to poison.
You may be able to be misleading though by using names that say one thing but do another, but again you'd be fighting against the tide of correctly named things.
There's the benefits that a lot of people mentioned, but to me the biggest benefit is I can avoid procrastination. Usually when I'm blocked on something I'll run a search in the browser, but very quickly I end up going off the trail and just browsing the web and losing a lot of time. Now when I'm blocked I simply type the comment of what I'm trying to do and the autocomplete suggestion is pretty damn good and unblocks me very quickly. More surprising of all, it somehow understands my code style by looking at the context.
I'll reproduce a generic example I sent a friend.
Prompt:
const redis = require('redis');
// Create a redis client
const client = redis.createClient();
// Get the current count from redis
client.get('count', (err, count) => {
if (err) {
console.log(err);
return;
}
// If there is no count, set it to 0
if (!count) {
count = 0;
}
// Increment the count
count++;
// Set the new count in redis
client.set('count', count);
// Log the new count
console.log(count);
}I will say, though, that it's also good at making up code that looks very believably real but doesn't actually work.
The ethics involved in Copilot are a bit strange, and I'm not sure I'll keep using it for those reasons, but it does a good job.
So, I actually consider this to be exactly the bad behavior that people accuse Copilot of.
Also, it’s like a more clever auto complete most of the time, even when it’s wrong in calling a function you can use it as foundation code to go faster.
And you don’t need to think too much about it, it really keeps you in the flow.
It sort of feels like pair programming with an undergraduate, except copilot never learns. That isn't to say it's bad, more that it is just a tool you can hand simple stuff off to, except the handoff is zero-effort.
EDIT: I will say that there are times when it makes up fantasy constants or variable names, that seem plausible but don't exist. An eventual version of Copilot that includes more normal autocompletion information, so it only suggests symbols that exist, will be a stronger tool.
I'm not sure. I think that understanding is omitting a "default amount" of boilerplate that will have to be written regardless of one's individual preference that is really a function of the language / framework of choice, the existing codebase and the problem at hand.
Removing that boilerplate would be ideal but is not always possible given limited resources, time constraints and the usual inability to make sweeping changes to the codebase
So we settle for the second best solution which is to automate away that tedious process (or short of that provide developers with tools to get it out of the way faster) so we can all focus on "real work"
In a way, it does the dirty pipes surprisingly well. But when it comes to implement the core of the algorithm, it is not there yet, but the potential is huge.
I am in the same boat with you. I am simultaneously wowed and underwhelmed to some degree.
Yes it is amazing when it gets right, it feels like cheating. But at the same time, it many times, does ... too much? To read a huge chuck of code and figuring out where it goes wrong is not a thing for me. Also Copilot doesn't really know the API, so yes, the amount of mental tax isn't less to make sure your program really behaves.
But again, I see the idea of Copilot is already huge win. I hate writing those manual scripts just offer people an entrance to some utility behind. Copilot does those things, surprisingly well and with accuracy.
Let it improve in the future, and we will see changes that quite fundamental to the idea of programming itself.
// Create a redis client
Press "r", press "." to autocomplete so it now says "redis.", then write "cC" and it suggests createClient (or write "create" or "client" if you're not sure what you're looking for). Now it says "redis.createClient()". Press ctrl+alt+v to extract a variable or write ".const" and press tab to apply the const live template. Ending up with your result in two seconds.
> than spend half a day tweaking test coverage on your one-off library
If you need to write a library and spend half a day to populate a list, you have bigger problems than boilerplate.
Nothing wrong with having duplicate lines. The problem becomes when writing those lines become automated so you start spewing those all over the place.
When I was playing around a couple years ago with the Fastai courses in language modeling I used the Python tokenize module to feed my model, and with excellent parser libraries like Lark[0] out there it wouldn't take that long to build real quality parsers.
Of course I could be totally wrong and they might just be dumping pure text in, shutter.
An impedance would be something to adjust the status quo in a negative direction e.g., a hardware failure
+1 for the variable extraction thing, I've been using their IDE for ages and it never occurred to me to look for such a thing.