Before launching into some philosophical musings about what programmers‘ crack addiction to code completion means, a few observations about my path.
In 2003, I started using Eclipse. Before that I had been using JBuilder a lot. Eclipse launched claiming that incremental compilation was the future and anyone not using it was lost. You would see your errors as you typed. I remember not being that thrilled at that prospect, but I did find, over time, that with eclipse, I was able to get an environment going that was very fast. The wheels started coming off of my love affair with it when first the WTP project turned up lame release after release, and then, after adopting Maven, the plugin situation there just produced stunted, epileptic madness. Also, I got to try Xcode, and wow, I thought ‘this thing is so much faster and cleaner, if only it had a few more things, particularly TDD stuff.‘ Well it has that stuff now and it is no doubt, IMHO, the best IDE there is. Of course, I cannot write big data programs with it, or web stuff, but for mobile and applications, it‘s nuts.
Lately, as per my ranting ‘documentation‘ on here, I have been using IntelliJ, first as part of Android Studio, then for a project using Play and Akka. It drives me bananas because it‘s so slow. I can‘t stand to work in it. I prefer to just tab over to the console and have play run my tests. It‘s really stupid too and it gets crossed up easily, then if I change things in the project, I have to regenerate the project files, which seems so many pales past a diaper I can‘t even really say the feeling it evokes. Anyway, by every other measure, I think that IntelliJ has eclipse handily beaten. Its ‘Live Templates‘ are much better than eclipse‘s templates, which evolved not one iota in the 10 years since I started using them (note, evolved meaning more than some minute crumb toss of silly improvements).
Recently, I stuck my head back into Sublime Edit. The reason is because I was using Bootstrap and I ran into it somewhere, then I saw this tutorial and was kind of ________ (insert your preferred phrase along the lines of blown away). First off, this thing is stupid fast. Secondly, this tutorial shows you things happening that are very compelling. I started to imagine, if I used this for Play, or Akka, what would I miss? Of course, the answer comes back pretty quickly: code completion.
Code completion is pretty great and I have showered as much love and praise on it since it crept into development as anyone. However, today, I was thinking about it, and I got to thinking, it‘s pretty baby-like. Like the IDE is offstage cooing for baby to open his mouth and have each cut piece put in, then to ask for more once that one‘s been chewed up. Now, the counter argument to this is that since the C++/Java cataclysm, we live in a world where we are programming with hundreds of APIs all the time. I have been using Hadoop a bit lately. It‘s a perfect example of what OSS engenders: a big, rambling barnyard of crap, another project for every single little crack that needs some caulk. One of the reasons that Xcode and Apple are such a pleasure is you can learn a framework and then use it for most of your coding, rather than constantly going in and out of tons of little halfwit pseudo frameworks that practice different conventions and have no concept of binding logic (they don‘t know who else you are working with after all).
So I started thinking, could I do some coding in Sublime? and what would that be like? My highest thing in a development environment is Speed of TDD, period. Above all else, then after that, it‘s probably code completion. But I think there might be ways to live without it.
The Staging of Construction
If you think about it, code completion is really needed for two reasons:
- you are either not familiar with the API of the thing you are using
- you are not familiar because it was badly designed and failed its heuristic challenge
What would you think the spread of this would be? I would say at least 80% of cases contain some of b. For example, no sane person would debate the fact that Joda is better than the JDK‘s time/date functions. However, I don‘t think Joda is a good API from the perspective of heuristics because I‘ve used it countless times and I never remember all its quirky silliness. I can‘t even remember its concepts, yeah ok, Instant, Duration, etc., but how they map those concepts, to me, is not great, and does not leave a lasting impression.
So now, we‘re saying baby has to have his/her food cutup because the wild west of everyone gets API mindshare means you‘re never going to know hardly anything of what you are using.
Let me pause for a moment to note the vast tragedy of this situation. The main reason its cosmically tragic, AFAIC, is that that is perhaps the main thing that objects were supposed to do that Structured Programming (methods) could not: as functions get more complex, their signatures grow beyond the 7 +/- 2 horizon (how many concurrent concepts a human being can keep suspended), and the ability to achieve any kind of fluency vanishes.
I have made this argument before, but the real genius of the modern version of Objective C is that through Categories, and its newer notation (esp. literals), it‘s kind of saying ‘let the user negotiate the last mile of making things more usable. And there‘s a ton of wisdom in that, because heuristics can often be impacted by need! I don‘t want to carry a ton of baggage when for what I am doing, I only need a small fraction of that.
Another possible solution to this is my favorite obsessive pattern: Builder. Bloch‘s Static Builder pattern largely make complex construction much more fluid and easier to navigate. Now, Builder is also PERFECT for code completion because the chaining this reference allows you to just keep going down and hitting . and getting another method to pick. One possible solution in ST would be to just program in a builder user plugin, that would read in the classes, grab the builders and parse them then suggest the methods. Or, it might make sense to just have a window that is open in a kind of sidebar configuration and as you start to go into the process of constructing or calling something, it would appear in that window, or its documentation, or maybe both.
Cocoa is one of the oldest and most mature frameworks, and by and large, code completion does not really make that much difference when using it. Partially because the methods are easy to remember, like ViewDidLoad or ViewWillAppear. But also, because you use them so many times, that you learn it and then don‘t really need much help with it.
Clearly, any kind of Lean consciousness about these matters has to see that the best of situations is but a tradeoff at this point: the programmer spent a few less seconds looking for a method call, but then, as tests were run and rerun in IDEs that are ludicrously slow, those savings were/will be bled back into the pool 100x over. People used to joke that C++ was the wrapper language. Wrappers are not bad things if they maintain fluency, especially on joints that are going to see a lot of traffic in the course of a long project.
Code completion is to IDEs as Outlook is to the PC: a boat anchor, encouraging people to just stay in their cabin, even as the ship takes on water from countless other directions. Until a native, blazing IDE is available for web development, finding alternatives to inline code completion might be the best escape hatch.
| Reference: | A Few Thoughts on Code Completion from our JCG partner Rob Williams at the Rob Williams’ Blog blog. |
