Parts of this rather remind me of Light Table. This may be intentional, but if not, you might find it interesting. http://www.kickstarter.com/...

Yes. We spend a lot of time reading code: one of the arguments for using vim is that it lets you move around code very efficiently: in most projects, the code is spread across a number of files, and being able to say stuff like "go to the definition of this function" helps reduce the time. I would say that your title is misleading: it’s not that "your editor is not the bottleneck", but rather that "your typing speed is not the bottleneck". If editors were only about typing, we’d be using something like ed, or just using shell redirection to type directly into a file.

"It's a pity that the main interface we get for looking at code is an editor, with its constant lure towards just changing stuff."
One of the advantages of having a writable view of code is that when you’re reading it, you can insert your own comments to explain how it works to yourself.

Finally, although typing may not be *the* bottleneck, sometimes it is enough of a bottleneck to hinder you: I prefer coding in vim to something like gedit because typing is fast, hence I don’t have to thing about it: I spend more time thinking about the code than thinking about "oh, I need to move up 20 lines to that function up there".

el editor no es el bottleneck, pero tampoco quiero que sea algo en lo que tengo que pensar demasiado. Mi setup es un vim casi sin ninguna customizacion mas allá de buena resaltado de sintaxis (para leer mejor), buena indentacion (para que no tenga que estar pensando en eso) y un plugin para saltar entre archivos mas rápido (para no pensar en eso).

no creo que el editor sea el bottleneck, simplemente quiero que entre el acto de pensar *quiero lograr esto* y lograrlo, haya la menor impedancia posible así no hay casos en los que me da fiaca hacer algo porque es muy complicado en el editor.

antes de vim usaba gedit, pero me pase porque me daba bronca tener que sacar la mano del teclado o tener que apretar 200 veces las flechitas para llegar a algun lado o hacer algo como copiar lo que esta entre parentesis o similar, ahora mi mente piensa "cambia lo que esta dentro de los parentesis" y mis manos tipean ci( (change inside "(").

he usado eclipse y visual studio por laburo, la cantidad de opciones, menus, overhead y sus intentos de "ayudarte" son insoportables. con tantas opciones, paneles, menus y vaya a saber que mas uno nunca descubre o aprende nada dada la cantidad de cosas superfluas que hay dando vueltas.

soy miembro del grupo "pensa antes de tipear" (raro que no nos vieramos en las reuniones ;)

para cerrar, el modo en el que normalmente uno esta en vim es el modo comando, no el modo inserción :)

You are going to be very happy with one of the future features of NINJA-IDE :P

I'll let you know when its there, so you can give it a try \o/

Ok, I'll take a bite at it (bias alert: I'm the author of PyDev)

The obvious thing missing is that surely as you said, you spend most of the time looking, searching and debugging your code, so, the must have features you need when developing (in an IDE or not) would be:

1. Searching for code (i.e.: in PyDev Ctrl+Shift+T would allow you to quickly browse and filter all the tokens available in your project and related dependencies, whereas Ctrl+Shift+R would allow you to get to any file you want). Here, you probably use something as some explorer tool as a replacement or ctags in an editor, or whatever different way of doing it the editor gives you -- but the IDE will usually (IMO) be better at this -- especially with go-to-definition and find-references integrated.

2. Seeing easy typos (i.e.: code analysis helps to show you got the name of a variable wrong and if some token you thought exists at a module actually doesn't resolve -- sure with a dynamic language such as Python, it's possible you get false positives, so, sometimes you may have to hint the IDE how to treat it, but I think it's definitely worth it) -- sure, you can run your test suite to give you those or use PyLint in the command line, but the time from typing to fixing is usually faster in an IDE.

3. Debugging: surely you do spend some time here, so, just having to execute a command to say: debug my last launch is probably faster (yes, you can pdb, but I think most agree a visual/integrated debugger will perform better here).

4. One thing that I find personally a time-saver is having auto-import when you want to use a token -- having to write an import seems to hold my flow of thought, so, having the IDE automate that is definitely a win for me, but I think the major thing here is not IDE or editor, just a way to type without disturbing your 'flow'.

5. Interactive console: yes, a shell is basically that, but I think it's nice to have it integrated with automatic imports, code-completion and other IDE niceties (so, this is probably a matter of taste).

6. I find it strange that sometimes people say that vi or emacs is faster to type, ok, after having mastered it for 5 years and comparing it with 7 days working in an IDE, that's probably the case, but I don't think that's the case if you compare someone that mastered the IDE to someone that mastered vi/emacs (I do get that as the IDE will cache many more things and is more RAM intensive, so, definitely, you may need more memory to work with an IDE -- if you still have a Pentium II with 64 MB of RAM, you definitely want the editor -- not so much with a Core i5 with 4 GB of RAM and an SSD), and yes, sometimes you do have quirks that may be related to the IDE and as a newbie may seem nonsense, but that's usually part of the learning curve for the IDE (as is having to get into edit or command mode in vi).

As for other tools, yes, you can probably have tons of things running in shells such as automatic unit-test, interactive console, opening a stack-trace location, an editor mod for go to definition, etc. so, you definitely want those things... you can have many shells open at all the times, one for the unit-tests, one for an interactive console, one for grepping, one for code-analysis, but the IDE does (IMO) give you a better experience (yes, it may have a learning curve, but so does vi and emacs... I still think an IDE does pay off in the long run, but I agree that if you really took the time to master an editor -- at which point you probably have an environment using many different OS tools that come close to what an IDE gives you -- you wouldn't be far off).

p.s.: Just noted I haven't even mentioned code-completion up there :)

The only real problem with what you said is that the file is the logical unit of code, like it or not. Virtually all languages support file-level and/or application-level global variables. Many languages, including C++, Java, and Python, support the execution of arbitrary code at file scope. That context is absolutely critical to understand the functions, classes, and methods within the file, nevermind the fact you may need to edit that code as well. As such, it's entirely inappropriate for an editor to neglect that information, nor is it appropriate to say that we never edit files.
You may want a better system for viewing that data, and that's not entirely unwarrented. I personally think that reasonable code organization (for which the editor can only do so much) and a usable outline view are sufficient. YMMV. I suspect a simple feature to "dim" the code you're not interested in would be sufficient to give you what you want. I don't know if any editors already support that, but it's probably not all that hard to add to one.
Fabio's comments are quite relevant to the broader points. A modern IDE is not just an editor, and all of those other tools are quite useful. I recently had to do a security audit on a very large codebase for which I had very little familiarity. All of the fancy tools in Eclipse to do searches, call graphs, lookups, debugging, etc. saved me a considerable amount of time, and Emacs does not do any of those things out of the box (and JDE is quite slow regardless). Of course, lots of people spend time microptimizing their tools just for authoring code (in particuar, emacs and vim users) and I personally find that quite silly, largely for the reasons you state. That being said, tools like automatic imports and code completion are quite useful, especially on large projects. I'm not sure they make me faster, but it does save me from having to leave the editor to look things up.
FWIW, I frequently use emacs when authoring code (habit from when I was working remotely and had litte other choice) but tend to make sure I have Eclipse or some other IDE around even if I'm not using it here and now. For Python, the debugger in PyDev is reason enough to have it handy! :)

The argument about calculating time based on lines of code is flawed in the sense that to produce 200 LOC may actually require many more lines, depending on how accurately you were able to think ahead. Experiments, refactoring, debugging all add up - as Peter said, in a good editor you don't need to think about how to move around.

This is why I have fallen in love with Sublime Text; while I found vim to be great for navigating within a file, Sublime Text blows it out of the water for navigating between files. While I'm sure that some combination of plugins could accomplish similar functionality, Sublime Text works out of the box, and works fantastically.

"SLOC [...] surely does work as a measure of how much a programmer
types, right?"

Whether that's true depends entirely on your language (and editor). If the language features syntactic abstraction, then yes. If it doesn't, and I need to depend on my editor to do it before it reaches the compiler, then no.

In Lisp, I can say exactly what I mean. If I need something trivial to be expanded, I write a macro to do that, and it's done by the compiler. So SLOC does correspond pretty well to how much I typed.

In Java, I can't say what I mean. The language has no support for a bunch of common repetitive tasks. If I need something trivial to be expanded, I need to expand it myself, which means I'm going to write an editor macro to do the dirty work for me. So SLOC can be far greater than what I actually typed.

Perhaps we should say "SLOC *should* correspond to what I type".

"we need better code readers not editors"

True, but unless you're using a pre-visual editor (like ed!), your editor is already also your reader. And being able to write a macro to read my code in a new and interesting way saves me a ton of time.

"You never want to edit
a file, you want to edit a function, or a class, or a method, or a constant"

Agreed! This is one of the things that live dynamic systems (like Smalltalk and Lisp) got really fantastically right. And we can still look down on VB. :-)

Ajá, yo también camino mientras pienso. Trece pasos, ida y vuelta, a lo largo de un corredor angosto. Eso cuando estoy solo; si hay mucha gente, cierro los ojos sentado en mi silla. Algunos han de creer que estoy durmiendo...

The editor may not be the bottleneck, but people seek to use the smoothest tools available for any task. I think that when you couple this with the fact that programmers are all capable, to some degree, of making the tools they are going to edit with simply by writing code, you end up with this obsession with editors - if I could easily machine metal components my bike would be very different. I also feel that doing a time saving study of what is gained by tweaking tools is missing the point of the exercise; I don't spend days and weeks making or tweeking things just to save those few extra seconds per use, I do it for the pleasure of using those tools afterwards.

Vos sabés que, hace poco vi en hackers news, un link en la que, lo que proponían era lo siguiente: que haya la menor distancia entre el creador y lo que crea. La idea era, más o menos lo que decís, si pudieras editar código e ir viendo al mismo tiempo como "se ejecuta" sería toda una experiencia distinta. El flaco mostraba un ejemplo con un video juego y, luego con un script que hacía una búsqueda binaria. La verdad, estaba muy bueno y, es exactamente lo que planteás vos (que me parece muy bueno también)... si encuentro el link, lo posteo.
Saludos!

You're forgetting that 200 lines is all that makes it into the checkin at the end of the task. There could be thousands of lines that are written and/or revised as you go about solving the problem, depending on how easy the problem is, the programmer's experience with the thing being coded, and how much debugging was necessary for, say, supporting multiple platforms.

Agree.

I agree with the statement of the title, as well as the plea for tools (including languages) that are closer to our level of thought. However, I question any conclusions based on averaging finished/committed lines of code over the workday. Among other reasons, the think-type-think-refactor-think-repeat cycle can well include bursts of effort in which I'm trying to pin down an elusive thought in concrete form. Excess friction at that point creates a disproportionate drag on the entire process.

That said, I look on reliance on analogies between programming and other disciplines with even more doubt.

All programming is not a single kind of thing. Should one really compare the lines of code written by programmers writing an O/S kernel, scanning a log for errors, and tweaking the appearance of a web-based payroll report? Isn't that as silly as "measuring" the work of a framing carpenter, roofer, and fine cabinet-maker by counting the number of square feet of wood nailed in place?

As for cooking analogies, I'll only point out that when one makes BBQ, the weight of the finished product is significantly less than the total weight of the raw meat and other ingredients. Even less, if we include the weight of the charcoal consumed in the process. And even less, if we include the weight of the grill.

I will admit that I think code becomes more tasty as we rid it of the excess fat.

One other consideration is that while you might spend 20% of your time typing, during that time you're trying to get the idea in your head out onto the screen as quickly as possible a) to make sure it works as you think and b) to get it in a less ephemeral format.

If it took me 5 minutes to write out a non-trivial idea for a solution I might lose my train of thought before it's done (this has happened to me in Java, by the time I'm done with the boilerplate I forgot what I was going to get done in the first place).

If one codes their classes correctly, wouldn't editing a file be exactly the same as editing the functions one is interested in?

As much as I wish it were like that, most programming more closely resembles this kind of painting: http://www.spiegel.de/inter...

The key is in the word 'editor'. Edit is not to write from scratch it has more to do with changing what is already there. I think you should focus on how to find the place you need to edit, how to get there, how to do the change and how to repeat it somewhere else. I would say that there is a huge penalty in time and effort if you have you use a mouse for any of those actions and in most editors that's your only option.

Some editors are harder to learn than others, racing cars are also harder to drive than street cars. Of course I wouldn't try to learn to drive a racing car if all I use my car for is to go to the market but if I'll be riding all day long I'd rather do it with a nice, fast and powerfull beast.

I use, usually, geany as my editor while programming. It's similar to kwrite, but gtk-ish. I agree with many of the things you said about this. I found it amazing to use a really easy & clean editor. Also I love tabs, and geany has tabs. My experience with IDE's wasn't good at all.