Looks like a nice implementation, and I really love JetBrains products, but for me I just don't 'get' this (or most code completion in general).
For me, and it is a personal thing, actually writing code - that is physically typing braces etc. is not the time consuming part of coding. Far, far more time is spent thinking about my code than actually typing it. Shaving off a few seconds when working in my editor feels like an optimisation too far, especially if it essentially means learning new syntax.
Like I said, it's a personal thing - I know others have good reason to love code completion tools. Now if someone could come up with something like this for when I'm writing in my notebook....
Autocomplete/parameter help isn't about "hey, look fewer keystrokes!". It's about context-aware lookup of what you need, and avoiding stupid mistaks (reordering parameters, typos in method names).
The time it takes to write a the first few characters of a method name and then hit the completion key is a tiny amount smaller than just typing the method name outright. But that isn't the point: if I didn't have autocomplete, I'd alt+tab to a browser with class documentation or start searching in the code for a previous invocation of a method with that name I only vaguely remember.
With autocomplete, I don't have to remember variable/property/method names, I can either list them or see a list that begins if I just remember a prefix. This is less unnecessary state in my head and thus more time to think about the actual problem.
It's an absolutely enormous difference in time spent, and considering the time it takes to context switch back to where you were, I'd say it saves me hours every day.
This. Autocomplete is like GPS for writing code in the presence of large libraries and complex APIs. It has nothing to do (at least now) with saving on keystrokes, and intellisense marketing docs post 1997 exclude this as a selling point.
The flip side is that by lowering the cognitive burden it breaks the feedback loop nudging programmers to create simple/elegant apis. I suspect we would be seeing fewer complex api's if there was less of a reliance on IDE's.
I'm not sure. You can look at dynamic language libraries and see similar increases in complexity (batteries included began with python), while they cannot benefit from code completion very much given a lack of static type info. The increase in library complexity is probably more related to demands on what we need to write where tooling is just a supporter.
Java and Python are good languages to compare here since Java appears to have the most money thrown at IDE's in the recent past. Python has a few IDE's but theyre nowhere as magical as Java based IDE's. The average python api that I have come across is usually much more concise than its Java equivalent and there is a strong culture of dwim in the Python community. How much of this is a result of the tooling support for either language and how much is a cultural artifact of the respective community is an open question.
On the other hand, typing 3-4 characters is faster than typing 20. Also, I think there is a kind of reverse "hey, look fewer keystrokes!" effect, though. When you have autocomplete, there is no excuse to not use long, descriptive names for everything. I think that style would be a lot harder to sell if it was not for autocomplete.
> I can either list them or see a list that begins if I just remember a prefix.
I think there is a deeper issue if identifiers are becoming so long that it's hard to remember them. But working with someone else's code is one of the few times I've found autocomplete to be useful, largely because it helps with getting around these issues.
Most of the code you have to call is probably part of a library/platform/runtime (e.g. jre, .net, boost, c standard lib). Even in small libraries it is difficult to learn all the type/method names by heart, and before you have used a function the first time, you have to discover/learn it somehow.
Identifiers (e.g. class or method names) don't have to be particularly long before you can screw up something silly like how to CamelCase it, or accidentally swap the order of a 2-argument method.
When I have reasonable domain knowledge, like say I include a vector math library, I can guess the type and method names and use the lib through autocomplete without ever looking at documentation.
I use code completion all the time, even when navigating APIs I've written myself -- not because I don't remember what they do, or what the functions and methods are called, but because it serves as a check that what I expect to be doing is what I'm actually doing. As a simple example, say I need to write `user.getAddress()`. Now, it doesn't pain me that much to type 'getAddress', and I'm pretty certain that the method that returns the user's address is called 'getAddress'. But if code completion doesn't offer that method as a suggestion, I'm going to do a double-take because I probably have the wrong object.
I do the same thing on the command-line: if I'm going to cd into a long path, I'll often forget I've typed cd and try to tab-complete file names instead of just directory names. When hitting tab refuses to autocomplete the file (it only completes directories), I'm forced to rethink what I'm doing before I finish typing an invalid command.
I think code completion would be enjoyed the most by those who don't know how to touch-type, since for them inputting the code is quite time-consuming.
But working with others (and occasionally using it myself), I've also found that code completion tends to encourage a "I think this is the right method/class/variable because it's in the list, I'll use it" type of thought process; and while it makes for easy generation of code that has no syntax errors, it also feels like it increases making logic errors since there is less thinking about "is this really want I want to write here" - it tells you what you can write here, and the instinct is to just pick the one that seems to feel like it would work.
Without completion I already code in the 100-120wpm+ range (and can comfortably write prose in the 150-160 range), so I don't think I need to make that any faster...
I think it has very little to do with writing and writing speed at all. Autocomplete is context sensitive documentation. Having to look away from the problem (at at web browser, another source file, or elsewhere in the same file) for hints about e.g. a method name, is very disruptive.
If someone would use autocomplete in the way you describe I don't think they'd be better developers without it. It's like saying we should all type with one hand since it makes us think more before we type.
Just to give you a different perspective on your second point, I prefer to use code completion as a way of checking if the API that I'm making makes sense to use. Sometimes I just want to be able to type out "assert" and hit cmd + space to see what assertion methods are built in. I feel like this was a major point of all the "fluent" APIs that came out on .NET after 3.0+ came out with Expressions and LINQ.
Whether or not this is the correct way to create an API for others to consume, who knows. But I tend to think of code completion as part of the "UX" of a library.
You can only really hit 100-120 wpm in bursts, and since programming is so mind dominated, it doesn't give you much of an advantage as someone who can burst at 20-40 wpm (reason why programmers don't list typing speed on cv's). Autocomplete doesn't improve burst typing speed that much since most people can type faster than the interrupted rhythm of a completion. Rather it improves API recall discovery times that are more thought intensive.
I respect your personal opinion, but I find that these little things make programming a joy. Less time spent fixing and changing little things is more time you can spend thinking about the problem.
Perhaps completion is not the most important thing, but surely it is useful - or not detrimental. It's something that, for some languages, can be done automatically by your computer instead of yourself. I'm all for the computer doing stuff for me. Be it so small as finishing the method name so I don't have to type it, listing the method set for me so I don't have to look it up.
The more the computer does, the better.
of course some argue otherwise, usually blaming IDEs as being a crutch for poor programmers. Surely it can be, but otherwise I say it's a very convenient tool.
Less keystrokes make my fingers and wrists happy. That said, I also do not care about "writing code" because if I could have a programming language that could read my thoughts to figure out what I wanted to create I would be just as happy with that.
This is for enterprise Java developers I guess. Interfaces, templates, whatever, ... thousands of lines of code that does nothing so one guy at the end of it can write a few lines of logic.
Or even better for testers. Lots of code. Some initial thinking and then you need to write 50 lines of something before you have to think about it again.
I totally agree with you. For me more important would be to improve the way how I solve problems, how I think about problems. People tends to pay too much attention to the speed of coding.
I wonder if any tests were made about how much time is spend to actual thinking versus coding the idea? Which area is more worth to work on?
>I wonder if any tests were made about how much time is spend to actual thinking versus coding the idea? Which area is more worth to work on?
I doubt it, if they did it would almost certainly be disappointing.
This is a question I have posed in the past, how helpful/useful is auto-complete/intelli-sense?
I think it is one of those IDE features that is similar to the automatic window slider in your car, you come to expect it because it does offer some convenience but adds little to your overall driving comfort.
It is indeed the case that most of what you spend time on isn't the code writing part when trying to solve problems. Typically you spend most time thinking about the problem and the actual code that results from that thinking can be just a few lines. Heck, sometimes the end result of thinking is to eliminate code:)
For me I think syntax highlighting and automatic syntax checking offers more utility than auto-complete. My startup's product is a web development tool that I now use as my primary IDE but it currently lacks automatic syntax checking, I can definitely say that this is something I miss from when I was using Netbeans.
Overall I think auto-complete has utility but the reverence for it far outweigh its actually utility.
It is more like the GPS in your car. Do you prefer looking at paper maps or the GPU unit telling you where to turn next?
Autocomplete allows libraries to get larger and more complex, for better or worse, since developers can just forgo documentation (paper maps) and rely on autocomplete menus (GPS). Your power windows don't help you drive at all.
There are so many different types of programming. Plumbing vs algorithmic is maybe one way to describe it. For plumbing, which is about moving data between systems or between a user interface and a database, there is often nor so very much thinking involved. It is the boring type of programming but I am sure the most common.
it's not about the speed of coding, it's about navigating the API and the existing code quicker. Those little helps are just so that you keep your brain at a higher level instead of focusing on tabs and semicolons. You focus on making loops, renaming variables, throwing exception, not on specific syntax things. Somehow it's the closest working things to all those visual languages they tried in the 90's.
it's not really faster, it just avoid de-focusing, it's the continuation of the bicycle for the mind thing.
I have to disagree, code completion allows my typing to keep up with my thinking. Sometimes I have a "picture" in my head about how to implement something and the only thing slowing me down is how fast I can get it into code.
Holy hell, that's awesome. I was reading through the blog and saw the headline, immediately went to check out chronon and was about ready to throw down the $60 for a personal license. Now I guess I don't have to :)
What excites me is the fact that when IntelliJ gets something cool like this, that usually means its other language IDE's are not far behind (RubyMine for instance..)
AppCode is the reason I still have hair. If I had been using XCode for the last 2 years I'd have it all pulled out by now. Or I might have given up on iOS altogether.
I often write code backwards using the IDE capabilities. Say I instantiate an object, I'd write "[[Foo alloc] init]" (most of that auto-completed), then use the keyboard shortcut to assign it to an appropriately classed and named local variable.
It just seems redundant to write all of "Foo *foo = [[Foo alloc] init]". For one you're typing the class twice - clearly redundant. Secondly, this is a temporary local variable, it doesn't need a custom name. It shouldn't have a custom name.
It's not so much about typing speed, more like a general dislike of redundancy.
The theorem is the more redundant the language, the more IDE help it requires. Objective-C is the worst I know. Although they're adding more and more layers to the compiler to make it less so.
This is really cool. One problem (yeah I know, Vim and Emacs commands are useful here too!) I always had was going forward is easy in a text editor, but going backwards a few characters, or to wrap something like this, is inconvenient.
When I saw the headline the first thing I thought was April Fools had arrived early in the form of a Forth IDE.
It is an appropriate name however. After dabbling in Forth for fun, I became very aware how fleeting and unnecessary local variables are.
Since then I use these kinds of 'completions' by using the extract variable refactorings, and various intent transformations - they added a syntax to existing tools.
IntelliJ is great, but I personally have found this feature to be minimally helpful and non-intuitive. I hope others benefit more than I have. Perhaps I shouldn't knock it, but I think that the time could have been spent on more worthwhile efficitncy improvements.
For me, and it is a personal thing, actually writing code - that is physically typing braces etc. is not the time consuming part of coding. Far, far more time is spent thinking about my code than actually typing it. Shaving off a few seconds when working in my editor feels like an optimisation too far, especially if it essentially means learning new syntax.
Like I said, it's a personal thing - I know others have good reason to love code completion tools. Now if someone could come up with something like this for when I'm writing in my notebook....