That's very nice and I'll probably be using it a lot, after VS2019 will stabilize (it's just a preview now).
However, the fact that this thing works so well, says a lot about the design of C++ standard library. They should have encapsulated the pair of iterators into a single structure, and implement implicit casts from vectors/arrays to that object. Requiring to type begin/end every single time is counterproductive.
Depends on the licenses of said projects. It's pretty easy to whitelist MIT/Apache licensed code.
Even still, it's unclear whether an abstract machine learning model that "saw" copyrighted IP during the training process is infringing on said IP. A self-driving car sees many billboards during test rides.
It's basically an extension of "everything is a derivative work". I believe it's similar to how you cannot (and should not be able to) erase your employee's brains of the code they worked on.
When you include the source code in a project? Or distribute binaries created in whole or in part from the source code?
The licenses say exactly what the requirements are, and when you are obligated to follow those requirements. What do they say about training AI models on the code?
Think of this more along the lines of when you read a code description of how something works and then describe it to someone else. In the same way that you don't have to provide copies of the license(s) of whatever you read, you shouldn't have to do that here, because the model is simplying learning and then inferring.
It's not as simple as that though. What if I train an AI to output a book given its title. With a sufficiently expressive and overfit network it could actually memorise the training data exactly.
That means my network now includes an exact copy of those books (encoded in a weird way but that is irrelevant). Should I be able to distribute my weights and ignore the copyright on the original books? Of course not!
In this case it is very unlikely that the network weights store much data from each individual github project, but it's definitely a sliding scale.
So is this basically like a Markov chain attached to a C++ analyzer? If so, then I think the title is a bit gratuitous with the whole "AI" thing, but I can't say it's not a convenient feature to have in an IDE.
This might use AI but it's nothing but marketing here. Isn't any sufficiently 'trained' program AI under this definition? If I put enough possible paths in my matching system, I get this. Intellicode is just a minor improvement on intellisense that could have been made years ago without any kind of AI branding.
I despise code autocomplete features. I could not stand using Jedi in Emacs. It just slows me down way too much to have to interact with an autocompleter. I’ll never understand why anyone would want this.
I’ve found code autocompletion to be particularly troublesome and hindering on large legacy code bases, where the suggestions not only prevent you from quickly typing out the method, class, etc. that you were trying to type, but also add a hindering layer of misdirection to trying to learn the architecture and code layout and form a mental model of the code organization.
Code autocompleters have only ever been pure waste to me, across a wide range of projects of various ages, states of code complexity, states of maintenance.
@mlthoughts2018
do you find that other aspects of your work pattern, and preferenceses are significantly different than of peers working on the same projects?
For example, do you think you use more of open source/3rd party libraries than your peers on the same project?
Do you find that many facilities in modern OS or languages are overly bloated, in your view?
What about project management methodologies -- do you have a preference?
Reason I am asking, is because your comment just does not correspond to my experience at all.
By now I cannot program without code completion, especially in the languages like JavaScript that do not have strong compile time verification.
It is also tremendously helpful for me in other languages I use, it helps me not just with my code, but reduces time of looking up basic API documentation for a new library that I recently incorporated.
I also often see that there is a duplicate function (even just from the names of functions, between my code and some library that I included in my project). So it helps me make quick decisions were I should remove code duplication.
So I am wondering if your perception is a result of a larger set of experiences/circumstances/choices that I did not take into account.
I have not found my preferences to be significantly different from my peers. I work mostly on large codebases all in Python with occasional compiled extension modules. The lack of compile-time verification in Python has not affected my work in the manner you mention about JavaScript. If anything, not waiting for long compile times (e.g. like in Scala which I also occasionally work in) improves my productivity and there are frankly just no serious classes of errors that get caught by the compiler in a time-saving way compared with low effort unit tests in Python.
I think the rise of bloated IDEs is a more modern phenomenon, popular with younger developers who were trained on those tools and haven’t invested time yet to learn there’s a much better way to work.
I've never found any of the autocompletion packages emacs had useful, mainly because their implementation continuously broke and they never felt solid. The story is completely different in visual studio code or visual studio for that matter.
Most autocomplete tools I’ve worked with were very solid and well implemented.
I did not find them useful because autocompletion while writing code is itself just not a useful tool conceptually, regardless of the quality of the tool.
Autocompletion for coding just doesn’t have any mainstream use cases or situations in which it can possibly be helpful. As a result, even very well made autocompletion tools cause trouble and hinder productivity.
On the other hand there can be niche, non-mainstream uses, like accessibility use cases for disabled people who have to use key entry mechanisms that make non-autocompletion key entry overly burdensome or slow.
However, the fact that this thing works so well, says a lot about the design of C++ standard library. They should have encapsulated the pair of iterators into a single structure, and implement implicit casts from vectors/arrays to that object. Requiring to type begin/end every single time is counterproductive.