I mean, I use autocomplete for work in python, ruby, golang, C/C++, JavaScript, coffeescript, CSS and probably more in enacts.
The trick is the setup, but I've only had problems with minor edge cases (like coffeescript 2). Either way I'll spend an hour and use Elisp to fix it. Really nothing I've found is even close to as robust
I find autocompletion in JetBrains and Visual Studio (disclaimer: haven't tried many others) to be outrageously good. Sometimes, in a dynamic/weak language, I wonder how the hell it can know what to suggest.
1) all the libraries are it takes advantage of are written in Java and this doesn't fit the closure style of coding at all.
2) the available tools just suck. Sorry, but without autocompletion the time it takes to write something balloons way, way too high.
I guess 2 would have been less of an issue 20 years ago -- back then most of the IDEs that we use today did exist -- but it is not 20 years ago. It is now.
That's not exact, it only works when certain conventions are followed, which is the situation we have now and will always have because unlike IDEs which typically autocomplete context free (or nearly so) languages your asking for auto completion to be done on what is essentially a very complex recursive language.
Autocompleting code and programming with others in mind are completely different (though related) tasks. It’s a copilot and it’s your responsibility to make sure it’s on the right track.
I get that, but I meant how often does it introduce bugs in the situation the OP mentioned, using it for "a language or framework you don't usually use", where I won't know if it looks right or not because I'm unfamiliar. Are they going back to fix the code often?
Personally, I don't even rely on normal autocomplete very much when I code because I feel like if I don't know what I'm trying to call, then I don't know the language or library well enough, and it's best to go look at the documentation.
Agreed. I don’t think programming with autocomplete is even a problem so much as learning to program with autocomplete is a problem. I think everyone should start out with a barebones text editor to get used to thinking things through and not relying on advanced IDE features as crutches.
It isn't Intellisense since it isn't using type information but the context of the text buffer to determine possible completions. Autocomplete is too vague.
But it's not. In fact intelligent completion is incredibly hard for dynamically typed languages. Those IDE that do perform intellisense or autocomplete with dynamic languages do it with very basic ability. In a real world dynamically written code file the editor simply has no way of knowing the members of a class. Or if it is even a "class".
> The reason I still use autocomplete is not that I need my IDE to tell me that there’s an ‘empty’ method there as if that’s something I don’t already know, but to tell me that my assumption that ‘myVector’ has an ‘empty’ method is correct!
Exactly, autocomplete is an excellent discovery tool. I may not even be aware productModel->hasConfigurableOptions was a function, or Product\Model\Configurable\Options was a model until I check with autocompletes.
Some are just lost if autocomplete in the IDE doesn't enter stuff for them, and the more verbosely the IDE spews, the better, cuz it looks like "work".
Why waste the mental space, especially with something you don't know you'll be using again? Not to mention the fact that api documentation can be difficult to find or may not exist at all. The Autocomplete knows exactly what methods are available.
I wouldn't disagree about learning the libraries you use frequently, but I personally work on a huge stack with more than 80 dependencies and memorizing their api's just isn't time well spent.
With good auto completion, the user should never even have to press the compile button or hit a compiler error. (Slight exaggeration)
This means the user might have struggled a long time with the code before even hitting the compile button. If you only collect statistics from compilation you will miss all this pre-struggle.
> Auto-completion is no doubt a large part of what's enabled your AbstractBeanFactoryProviderImpl to get those 33 methods in the first place. Which is a big part of my point, autocompletion shapes the way you think about code, shapes how you write code.
Sure, but that doesn't necessarily make it better or worse. People have written horrible code without auto completion, just like they have written horrible code with auto completion. I'm not convinced that you just magically get better at thinking by making your life harder and typing more for no real reason.
> There are also a lot of examples of functions that, by name alone, do not do what they seem to do. That shouldn't be, you might say. But even in the face of that objection, they do exist. It would be very easy to jump to the conclusion that for example "Boolean Boolean.getBoolean(String)" parsed the string and returned its boolean equivalent.
And not having auto complete doesn't help with that at all. Auto complete MIGHT also include commentary for the function and explain what it does (if that commentary exists in the first place) and at least help with the issue.
It is possible to use libraries correctly.
It is not possible to use AI correctly. It is only possible to correct its inevitable mistakes.
reply