Honestly I just ditched the idea of Copilot the moment it spewed out an entire file of copied code. Nice work on making a markov bot with extra steps GitHub. Please, do take my money..
The Good and the Limitations of Github Copilot
71–80 of 144 posts
Re: The Good and the Limitations of Github Copilot
#72Earlier quoted context omitted.
> I think Copilot should report the matching source URL That's the problem. The output of a GAN like Copilot usually can't be traced directly back to a single input.
If you can't trace the source then it's transformative use. If it matches training data then it needs to report the source like a search engine and place all responsibility on the user. And fuzzy code matching could be easily implemented by using the a model similar to CLIP (contrastive) to embed code snippets.
That's not how "transformative use" works.
Re: The Good and the Limitations of Github Copilot
#73I wonder how much worse or better simply automating a stackexchange search and pasting the results is...
Re: The Good and the Limitations of Github Copilot
#74Earlier quoted context omitted.
Hey Chris I am the author. When i made the video I didn't really notice the code part of regex, since I am really new to regex but in the conclusion part of my video I did mention that most of the code is not efficient Your comment was a great learning . Thank you
This is exactly the problem. The regex issue isn’t that it’s not efficient, it’s that it’s wrong. Using this tool to generate code in a problem area you are not qualified to double-check and validate yourself is dangerous.
You are taking yourself to serious.
Re: The Good and the Limitations of Github Copilot
#75Earlier quoted context omitted.
This is exactly the problem. The regex issue isn’t that it’s not efficient, it’s that it’s wrong. Using this tool to generate code in a problem area you are not qualified to double-check and validate yourself is dangerous.
>validate yourself is dangerous You are taking yourself to serious.
Re: The Good and the Limitations of Github Copilot
#76Earlier quoted context omitted.
How is it better to have "simple" emails?
It depends on the use case, but for some business use cases you e.g prefer access to the end users default/canonical inbox and not a specific one the user can use to filter etc. It’s also much less likely to cause downstream problems like distribution issues, be rejection by spam filters and so on. Annoying a tiny fraction of users or losing their business just isn’t a big enough issue to matter.
Those are not legitimate uses.
Re: The Good and the Limitations of Github Copilot
#77Earlier quoted context omitted.
> Using this tool to generate code in a problem area you are not qualified to double-check and validate yourself is dangerous. I would like this message to be amplified as much as possible. Never write code you do not understand. I am excited about copilot, but also wary of the programming culture these tools will bring in. Businesses, especially body-shopping companies will want to deliver as much using tools in thi…
Isn't "Code you don't understand" the definition of AI/ML?
Re: The Good and the Limitations of Github Copilot
#78Earlier quoted context omitted.
Copilot acts like a search engine, you search, you find, then you judge. It was never the case with search engines that you could just copy some code you found without verifying it. Also, it has the same copyright problems as if you used Google to find the code.
Does GitHub Copilot tell me which license the code it suggested has? If not it's a huge difference to code search engines.
Re: The Good and the Limitations of Github Copilot
#79A fun issue I keep hitting with Github Copilot in Python is that it's a coin flip whether it will give me a Python 3-style print statement or a Python 2.7 style print statement.
Most instances of that should be fixable with some post-processing in Copilot. They could maybe even run py2to3 on it?
Re: The Good and the Limitations of Github Copilot
#80Earlier quoted context omitted.
It depends on the use case, but for some business use cases you e.g prefer access to the end users default/canonical inbox and not a specific one the user can use to filter etc. It’s also much less likely to cause downstream problems like distribution issues, be rejection by spam filters and so on. Annoying a tiny fraction of users or losing their business just isn’t a big enough issue to matter.
The only use case you're describing is being able to send spam or sell the user's information to third-parties while preventing the user from identifying that, or from filtering e-mails coming from your service. Those are not legitimate uses.
Even if I have no interest in selling emails, it's still a net benefit if leaked data (e.g. after a breach) isn't full of bob.smith+mycompany@... rather than bob.smith@