Ridiculous. The argument apparently assumes that the only time spent in the editor is writing code. Not writing tests, or documentation, or email, or for reading code, or searching code.
So sure: if you only use your editor for typing in code, it's "not the bottleneck" to getting your code typed in. The problem is that if you're using you're editor like this, your editing skills are absolutely the bottleneck to doing productive development.
There's also the question how how that 100-200 LoC number is measured. They're looking at code that actually got checked in to the project they're looking at. I write less than that at work, but there's also an iceberg of code that wouldn't ever get counted. Iterating on multiple revisions before checking one in. Throwaway experiments. Side projects (the only reason I have them is that with fewer constraints they let me stretch my legs and code up a storm).
I don't necessarily agree with everything written here, but I think it is a good discussion starter. Personally, I think the editor has a huge part in the "code reading" and "thinking" phases. In the former I jump around a lot, and a code reader would end up looking like vim or eclipse or whatever with insertion disabled, and replaced with some sort of annotation mechanism (instead of just inserting comments). I understand that there are other cool things a reader could do, but they would be most useful as additions to an editor anyway, as they have uses in editing and maintaining as well. For the later, I do sometimes walk away from the problem to think, but other times I jump around and look at various bits to help remember the "shape" or imagine how the "shape" of bits would change with my latest ideas.
I disagree with the author on a number of levels. First and foremost, he/she's treating the editor as if its sole purpose in life is the invention of new code. This seems like a somewhat stilted view of reality to me. Features like syntax highlighting, syntax aware block indentation, and project aware search are easy wins in terms of ROI.
Also, they bemoan the fact that for many people their editor is also their primary code reading environment, but it sounds very much to me like what they're asking for is amply provided for in a modern IDE.
While I agree that fixating on a particular tool can be a waste beyond a certain point, IMO a programmer investing in learning their editor seems like time well spent to me.
I disagree with this for a few reasons. Having an editor or tools which feel cumbersome and don't get out of the way, in my anecdotal experience, may cause me to avoid it more often (visit sites like this for instance) etc.
In addition, often when learning new features of an editor or IDE, I enjoy applying it to actual code, which causes me to spend more time coding, which does impact SLOC.
Learning vim features such as autocomplete also save context switches where as previously I would have had to have a browser window open with the documentation. Just my two cents, I think it really does matter.
I don't believe he is saying to use any editor. We could easily list ten of the best ones than meet your standards above. Someone proficient in one of those is probably going to do just fine.
Forget about the speed. Using the right tool for the right job makes you feel better while you work. This not only increases productivity and quality of the product, it also keeps your workers sane. The obsession with finding the right editor (and the right vimrc for it) goes way beyond producing code fast.
I don't know how most other people code, but I rarely write out a module, even from scratch, in a way that doesn't require editing and rearranging. I start with a skeleton which reflects my best understanding of the problem and then try my best to fill it in with code. Sometimes the organization is not quite right, or sometimes you realize you need an extra parameter somewhere that is out of scope; but whatever it is, there's always some kind of stumbling block that requires reorganization.
The overall shape is usually close enough, but it always requires refinement. That refinement happens in a loop; you move stuff around, do a little nip tuck, maybe attempt to fix some bugs, and then run the module (or the tests). Optimizing this loop is important (it's one of the major benefits of scripting languages); once you figure out what change you should make, or what experiment you should run, the faster you make it happen, the faster you get the results, and the faster you can get back to the important mental aspect of figuring out how to fix or create whatever you're working on.
Of course the editor isn't the bottleneck. That doesn't mean that it isn't still the most important tool of the programmer. And there are editors and there are editors. We all have our favorites. Some people get along fine with editors that are nothing but less buggy versions of notepad. Others want their customized Vim or Emacs experience.
The problem with a bad editor is not that it wastes time, but that it generates many small interruptions, in the form of awkward editing tasks, which can break trains of thought. The cost of this is drastically higher than the time spend would indicate.
Your editor is not the bottleneck, but reducing the distance between your thoughts and the code is still pretty important. You want to be able to move around, type something and change your mind in the most immediate way possible. Whenever I have to revert to an unfamiliar or inferior editor and can use no motions except from the mouse or arrow keys, I feel like everything becomes harder because I'm not "in" the code.
In the same way, having a compile time of 10 seconds instead of < 1 second is probably the main bottleneck when you code, but your productivity will suffer.
Goodness, this is depressing. I wonder what on earth this guy would say about my breaks to play foosball?
Configuring an editor can be thought of as a similar thing: it can be a fun break from programming, and if it even slightly increases productivity, then that's a win.
I don't think any editor person would argue that using an a particular editor gives a really massive increase in their productivity, but why shouldn't we use specialist editors? It just feels good to write with them, and that can't be a bad thing.
I would say solving the right problem is the bottleneck. Who the fuck cares what editor you use? Generally, they all work. Startups don't fail because:
1) You can't search through code quickly enough.
2) You couldn't secure the next round of funding because no one was using Sublime Text, or TextMate, or IntelliJ, or Vim, or Emacs.
3) It didn't have all the fancy features that essentially boil down to developer masterbating.
Remember, all startups are supposed to solve a problem that is worth money. WE SERIOUSLY NEED TO STOP TALKING ABOUT EDITORS PEOPLE! Start ups fail because you are solving a problem that doesn't need to be solved, you can't find product-market fit, you have a shitty UI that no one can figure out, your applications are slow or have crazy down-time, or you fail to reach enough of your market to sustain a functioning business model, etc.
None of the problems are code. Code is a means to an end. I'd say code editors are sad not because they focus on the file instead of the class, module or function. I'd say code editors are sad because they focus on code in general that only exists because solving the real problem another way isn't possible.
Let's focus on solving the right problems. Problems that need to be solved, and not problems that look like other problems.
Can we all agree to stop posting text and code editor reviews and editorials and focus on becoming a more integrated component of a larger business? Just for one week, let's not talk about editors and instead think outside of our developer box.
Sorry for the rant but this sort of discussion is not productive, produces flame wars, pedantic quibbling and we never end up anywhere else than where we started. Code editors are like butt-holes, everyone has one and they all stink for one reason or another. Let's not forget that they exist to put poop in the toilet.
*Edit: Some have made extremely valid points that its not all about business, start-ups or money. I agree. My more broader statement is this: the editor one uses is largely a matter of preference and is not the determining factor of success for any project, professional or otherwise. Being able to solve the task at hand (whatever it may be) is largely a function of the focus, determination, experience, and skill of the person using it. At the end of the day which editor you use shouldn't make a damn bit of a difference of the actual bits you compile.
Equally, I'll bet that no startup has ever failed because the developers spent too long configuring their editors.
Why the hell does it matter so much to you that people enjoy being good at using a powerful tool? If you don't want to see editor articles, downvote them, or move to another website, or filter them out (either mentally, or programatically).
Actually, I think that a bunch of startups failed because of not configuring their editor, not writing tests, not doing code reviews and refactoring, not automating anything and generally by not taking the time to clean up things.
Maybe not - I'll give you that. I do imagine startups fail frequently because they focus on problems that aren't actually problems. Considering the level of debate about code editors here on HN its not too much of a stretch that as an industry we get distracted by things that are generally not that important in the overall scope of things.
Your comment makes the implicit assumption that code exists entirely for the purpose of powering a business. Code is also a creative medium for expressing ideas and the craft of programming in and of itself is of interest to many people.
100% agreed. alttab is falling into the common geek social trap of assuming that all the world is exactly like him/her. Personally? I couldn't care less about start-ups. I'm happy that they exist, I appreciate the innovations they create, and I enjoy the fruits of their labors, but to act as if the alpha and omega of existence is solving the problem of what causes start-ups to fail is IMO fundamentally both arrogant and wrong headed, because start-ups represent only a small percentage of the tech world at large.
200 lines of code is the average. What's the standard deviation? There may be some days I write 20 lines of code, and there may be some days I crank through 1000 links of code.
If your editor limits the max it impacts the average. If the days when coding dominates were more productive you could have fewer of them and spend more time designing, testing, writing documentation.
I share the sentiment. Are there any good code readers? Something that could show better what actually lies in your code better than highlighted text does?
So sure: if you only use your editor for typing in code, it's "not the bottleneck" to getting your code typed in. The problem is that if you're using you're editor like this, your editing skills are absolutely the bottleneck to doing productive development.