481–490 of 771 posts
Earlier quoted context omitted.
Eh, as long as my employers don't care (they don't), I don't care. I have no illusions that my code/our code will give Microsoft any valuable training data it couldn't trivially get elsewhere.
Mine does, and therein lies my issue.
Earlier quoted context omitted.
So there is 100% feature parity then for all other editors other than VS Code then? YES or NO? As I said before, "They are more 'Committed' to supporting VS Code than giving total feature parity to other editors." Sticking a bunch of logos with no guarantee of 100% feature parity as seen in VS Code is exactly what lock-in is. > If anything, VS Code is a way for Microsoft to push other services like Copilot. The strat…
> So there is 100% feature parity then for all other editors other than VS Code then? YES or NO? Yes. If you had taken the time it took to look up your comment to actually do something productive like looking this up, you'd have probably found it yourself. Yet, here we are. Copilot fully supports JetBrains and NeoVim alongside Code and VS: https://docs.github.com/en/copilot/getting-started-with-gith... https://docs.g…
Bait and switch. If it's good enough that Neovim users can't live without it, pulling the plug from Neovim support will result in some subset of users converting to VS Code. Probably won't play out this way with Jetbrains, but editors with smaller following and nobody backing them will most likely suffer this fate. It's happening all the time, most notably with Google products. Google Talk that used XMPP was neat and I switched to it because I could use Pidgin to contact most of my contacts. Not only Google Talk stopped supporting the standard, it even died and was reborn as something else I think 3 or 4 times by now. Of course, my contacts stayed with Google, so I had to leave Pidgin behind. It's going to be similar here, though to what extent I'm not sure, maybe it won't be very noticeable, or maybe it will. We'll see.
Microsoft really seems to have wrapped up the developer ecosystem with VS Code and the Github acquisition combined with OpenAI. They are going to have an absurd amount of data to optimize their models thanks to that, not sure how other AI focused companies can overcome that have to wonder at what point developers remember how anti-developer Microsoft used to be and potentially move away from their ecosystem. Credit t…
Earlier quoted context omitted.
Copilot user here. Copilot (the existing gpt-3 one) definitely helps at writing unit tests. Yeah, sometimes it doesn't nail it, but one thing it can do reliably is to repeat a pattern, and I don't know about you, but my unit tests tend to repeat the same pattern (with some tweaks to test this-or-that-case). Quite often it infers the correct change from the name I gave the test method, but even if it doesn't it'll wri…
> one thing it can do reliably is repeat a pattern Isn't this something we've built into every modern language(and arguably the entire point of languages)? If you have multiple pieces of code that share code with tweaks(to test this or that case for example), shouldn't you parameterize the bulk of the code instead of getting autocomplete to parameterize it for you and dump it into your source file multiple times?
I think they've done it backwards in regards to it writing tests. Tests are the check to make sure the A.I is in check. If A.I is writing tests, you have to double check the tests. You should write tests, then the A.I writes the code. It almost doesn't matter what the code is, as long the AI can regenerate the code from tests.
Tests don't (can't) prove tthat code is correct. They are merely a rough plausibility check that the code isn't completely wrong and didn't regress. You generally can't derive the right code just from tests.
I've even written tests that say this set of input goes to this output, for various different subsets of input. Anything outside of the of the defined input sets fail validation.
Than it randomly picks a couple of thousand inputs from the input sets I've defined and runs them. More confidence you need, the more exhaustive setting you put it on.
It's a bit like QuickCheck.
Earlier quoted context omitted.
Apple has always had its own hardware based silo to some extent (excellent products and design, fully integrated). Still, I suspect the AI stuff will be hard for them. They were first to market with Siri and it’s still trash 13yrs(?!) later. It’s always been what they’re weakest at, I’m not sure LLMs will be different for them. The headset could still give them a nice hardware platform advantage though if that UX bec…
AI in support of user interface has been downright awful. IIRC, Siri has the lowest customer satisfaction out of any other product at Apple. However, the company has deployed machine learning in support of its neural engine which has a huge amount of penetration. This has already shown the iOS fleet ready to do gen AI at the edge. The company has focused largely on STT and image processing but has worked to support u…
This is so true that now the only differentiating capability is execution, and I'd say that Microsoft is excelling here in an unexpected way.
Earlier quoted context omitted.
Copilot user here. Copilot (the existing gpt-3 one) definitely helps at writing unit tests. Yeah, sometimes it doesn't nail it, but one thing it can do reliably is to repeat a pattern, and I don't know about you, but my unit tests tend to repeat the same pattern (with some tweaks to test this-or-that-case). Quite often it infers the correct change from the name I gave the test method, but even if it doesn't it'll wri…
> one thing it can do reliably is repeat a pattern Isn't this something we've built into every modern language(and arguably the entire point of languages)? If you have multiple pieces of code that share code with tweaks(to test this or that case for example), shouldn't you parameterize the bulk of the code instead of getting autocomplete to parameterize it for you and dump it into your source file multiple times?
Here. We. Go. I made the analogy a few days ago about how all modern manufacturing and machining processes were essentially bootstrapped from two fairly flat stones. Its going to be interesting to see how the acceleration in improvement of the tools for "making things" changes in the LLM age.
"When two plates are not flat but still match, one will not match the third. By continually lapping or scraping the high points of their contact until all three show perfect bearing when intercompared, three flat planes are created" [1]
[1] Foundations of Mechanical Accuracy by Wayne R. Moore c. 1970
(An absolutely fantastic read)
There are 5 different sign-up waiting lists. Each one needs to be signed-up for separately. [1] Copilot X: https://github.com/github-copilot/chat_waitlist_signup/ [2] Copilot Voice: https://githubnext.com/projects/copilot-voice/ [3] Copilot Docs: https://githubnext.com/projects/copilot-for-docs/ [4] Copilot for PRs: https://githubnext.com/projects/copilot-for-pull-requests/ [5] Copilot CLI: https://githubnext.com/pro…
The resulting code was pretty decent except it included a hard coded access_token in the url. This was a blank project, I don't even have an access token for this api - guessing someone posted theirs in a public repo at some point.
Is there a way to talk to copilot at this point to refine the code?