2 ms·

It takes what should be your method of last resort - copypaste - and makes it the first thing you try. All the steps in between - looking at the docstring for

It takes what should be your method of last resort - copypaste - and makes it the first thing you try. All the steps in between - looking at the docstring for the function you're calling, googling for more general information, looking at and deciding not to use not-applicable or poorly-written SO answers - get pushed aside. So instead of you having to convince yourself "yes, it's safe to copy-paste these lines from SO, they actually fit my problem" you're presented with magic and I think the burden for rejecting it is going to be higher once it's in your editor than when you're just reading it on a SO post or Github snippet. Even for a newcomer looking to learn, working on simple stuff that it has great completions for, it seems like it will sabotage your long-term growth, since it takes all the why and the reasoning out of it. Autocomplete for a function name isn't that relevant to gaining a deeper understanding. Knowing why a certain block of code is passed in in a certain style, or needs to be written at all? Probably that is.

majormajor 5y ago
Thinking about it more: there's a very small subset of problems that I think this is actually great for. And I do run into this somewhat often: relatively new libraries or frameworks that don't really care about thorough documentation so they only show you a few happy path snippets and nothing about how to do something more interesting, so you have to bridge the gap between "this one line in the doc obviously doesn't work with me, but I'd like to figure it out without reading all their source code from scratch..." - getting more example snippets barfed up onto my screen from other people who've figured it out before could be a sort of replacement for the library writers having provided documentation in the first place. But ... this is a somewhat insane way to work around a problem of shitty code documentation, and is still insufficient in a couple ways: * some poor bastard is going to have to be the first person to figure out how to do something, so that copilot itself can know * any non-code nuances around "oh, if you do that, your memory usage is going to explode" or "oh, by the way, if you do that, make sure you don't do your own threading" will still fail to be communicated.

majormajor 5y ago

Thinking about it more: there's a very small subset of problems that I think this is actually great for. And I do run into this somewhat often: relatively new libraries or frameworks that don't really care about thorough documentation so they only show you a few happy path snippets and nothing about how to do something more interesting, so you have to bridge the gap between "this one line in the doc obviously doesn't work with me, but I'd like to figure it out without reading all their source code from scratch..." - getting more example snippets barfed up onto my screen from other people who've figured it out before could be a sort of replacement for the library writers having provided documentation in the first place. But ... this is a somewhat insane way to work around a problem of shitty code documentation, and is still insufficient in a couple ways: * some poor bastard is going to have to be the first person to figure out how to do something, so that copilot itself can know * any non-code nuances around "oh, if you do that, your memory usage is going to explode" or "oh, by the way, if you do that, make sure you don't do your own threading" will still fail to be communicated.