Your Editor is Not the Bottleneck
This may cause some palpitations in some friends of mine who laugh at me for using kwrite, but it really is not. Any time you spend configuring, choosing, adjusting, tweaking, changing, improving, patching or getting used to your editor is time invested, for which you need to show a benefit, or else it's time wasted.
Let's look at SLOC, which while discredited as a measure of programmer's productivity, surely does work as a measure of how much a programmer types, right?
Well, estimates of total code production across the lifetime of a product vary (just take the SLOC of the product, divide by men/days spent), but they are usually something between 10 and 100 SLOC per programmer per day. Let's be generous and say 200.
So, 200 lines in eight hours. That's roughly one line every two minutes, and the average line of code is about 45 characters. Since I assume you are a competent typist (if you are not, shame on you!), it takes less than 20 seconds to type that.
So, typing, which is what you often tweak in your editor, takes less than 15% of your time. And how much faster can it get? Can you get a line written in 10 seconds? Then you just saved 8% of your day. And really, does your editor isave you half the typing time?
How much time do you lose having your eyes wonder over the sidebars, buttons, toolbars, etc?
So while yes, typing faster and more efficiently is an optimization, it may also be premature, in that, what the hell are we doing the other 80% of the time? Isn't there something we can do to make that huge chunck of time more efficient instead of the smaller chunk?
Well, I think we spent most of that time doing three things:
Reading code
Thinking about what code to write
Fixing what we wrote in that other 20%
The first is easy: we need better code readers not editors. 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. I think there is a lost opportunity there somewhere, for an app where you can look at the code in original or interesting ways, so that you understand the code better.
The second is harder, because it's personal. I walk. If you see me walking while my editor is open, I am thinking. After I think, I write. Your mileage may vary.
The third is by far the hardest of the three. For example, autocomplete helps there, because you won't mistype things, which is interesting, but more powerful approaches exist, like constant running of tests suites while you edit. Every time you leave a line, trigger the affected parts of the suite.
That's much harder than it sounds, since it means your tools need to correlate your test suite to your code very tightly, so that you will see you are breaking stuff the second you break it, not minutes later.
Also, it should enable you to jump to the test with a keystroke, so that you can fix those tests if you are changing behaviour in your code. And of course it will mean you need tests ;-)
Which brings me to a pet peeve of mine, that editors still treat the file as the unit of work, which makes no sense at all. You never want to edit a file, you want to edit a function, or a class, or a method, or a constant but never a file. Knowing this was the sheer genius of ancient Visual Basic, which was completely ignored by all the snobs looking down at it.
So, instead of tweaking your editor, get me a tool that does what I need please. I have been waiting for it since VB 1.0. And a sandwich.
UPDATE: Interesting discussions in reddit and hacker news
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, the edit/test cycle thing was vaguely remembered from that, I should have mentioned it.
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 :)
Thanks for the thoughtful comment! :-)
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! :)
Many languages I use don't attach much special importance to file scope. So while "virtually all" do, does that include languages like BF and COBOL and Fortran that I'd never actually want to use? Virtually all animal life on earth is insects but I'm not going to run into a trillion insects on the way to the corner store so it doesn't really matter to me.
Many languages I use do attach some importance to file scope, but it's always less significant than other scopes. Why then does the editor present the file scope as being of primary importance? As you say, when the language does something, "like it or not", then the editor should support that. Languages attach a secondary importance to file scope, so editors should, too. Nobody is saying that files should become completely invisible in editors, but they should at least delegate this to the importance that it actually has.
I having a hard time of thinking of any langauges that don't attach much special importance to file scope, much less many, so I'd love to hear what you think they are. Even Java provides for "file-scope" arbitrary actions through static initalizers.
Even in languages like C, where file-scope is limited (which doesn't ipso facto reduce its importance), you can still define and declare types, constants, and variables, all of which are critical to understanding the execution of a function and its correct behavior. Trivial example: In Python, you can access file-scoped variables in a function, though you cannot rebind them. Obviously, the use of the file-scoped variable is critical to the correct understanding of the function. Most languages have similar scoping rules so that an editor that totally hides those variables is doing the user a disservice.
Languages that only allow, for say, import directives and function / type defintions are the exceptions, not the rule.
Smalltalk.
In some implementations, not others. At anyrate, for every SmallTalk and LISP, there's hundred Algol derivatives.
Sure, just giving you one example since you said you had a hard time thinking of one.
"I having a hard time of thinking of any langauges that don't attach much special importance to file scope, much less many, so I'd love to hear what you think they are. Even Java provides for "file-scope" arbitrary actions through static initalizers."
You could have all your Java project code in a single file if you wanted.
That Java provides "file-scope" actions doesn't mean that files are not a logical unit of Java code -- the same way that my fridge can make ice cubes does not make it an ice cube machine.
No, you cannot, because Java requires one public class per file. It's very doubtful you'll be able to create a Java program of any meaningful size that consists of just one public class.
And your attempt at an analogy is just logically false. There's nothing that requires something to possess a singular identity, a refridgerator may be both a fridge and an ice cube machine.
And of course, all Java programs are equivalent to one with only one public class, and there are obvious workarounds were you so inclined to write crappy Java: http://www.roseindia.net/ja...
That doesn't do what you and the author think it does. Public nested static classes are not the same as public outer classes in many respects, so you cannot automatically substitute the former for the latter. They will create issues with reflection and name lookup in many dynamic contexts.
If you say so! I don't know enough Java to see those pitfalls.
"The only real problem with what you said is that the file is the logical unit of code, like it or not. "
Logical it is in no way. Classes, functions, modules, imports, projects, packages etc are the "logical" units of code.
Code has nothing "logical" to do with files and/or the filesystem.
A file is just how editor sees your code.
If I can execute runtime statements in that level of scope, then it must be a logical unit of code. Otherwise, how could the code be executing? How could the C++ static order initialization fiasco exist if a file wasn't a logical unit of code?
Really, I'd happily an even stricter definition for logical unit: if it creates a scope, then it must have meaning to the language and ergo be a logical unit of code. I don't see how any stricter definitions are workable, nor do I see how any wider definitions are meaningful.
Please notice that I did not say "logical unit of code" in the article, I said "the unit of work", trying to mean something like "the thing you manipulate".
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.
Yes, but if to write 10 lines of code you have to write 100, then there is something wrong in your process, just like if to cook one cookie I had to spend 10 pounds of flour.
Cookies have already been invented, though, and there are countless recipes available. If the concept of a "cookie" had not been invented yet, could you bake me one correctly the first time?
How would you respond if, when you couldn't, I accused you of having "something wrong with your process"?
If I had a cookie factory and every cookie I sold involved 10 pounds of flour, yes there is something wrong with the process. The analogy is not the thing.
Nonsense. Most of the production applications I've written were written twice, usually once in a "prototyping" language (e.g., MATLAB) and once in a "production" language (e.g., C++). The codebases tended to be of comparable size, all things considered.
If your universe of production applications is one that starts as MATLAB prototypes, may I suggest that it's far from representative of anything other than scientific research?
Perhaps, but it also means your rather hasty dismissal of how much code might be discarded per line of production code is entirely inappropriate. It's quite common in some domains and process methodologies to generate considerable amounts of code that either gets rewritten and/or entirely discarded.
Yes, in some domains and methodologies. Sorry, it was a blog post, not a scientific paper full of careful considerations and exclusions :-)
Even in that case, with the two codebases of comparable size, you get at most 400-500 lines per day.
Same order of magnitude. A factor of 2 upgrade, but still nothing interesting type-wise. 500 lines for 8 hours?
Yes, I'm not sure it's not relevant to the conclusion of the blog post, but I think robertftw's point (which I was supporting) is that looking at final SLOC doesn't give you a very good final productivity metric, since lots of code written during a project may be rewritten or tossed.
But even if you increased the metric, I think the conclusion is still the same.
I was interested on trying to think about the impact the constant editor tweaking on which most coders indulge may or may not have on their productivity, and that was the metric I could think of. Improvements welcome :-)
"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. :-)
Yay for the added bonus of continuing condescention! ;-)
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.
Valid point.
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!
Este es el video:
http://vimeo.com/36579366
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.
True. I am open to better metrics if you have any :-)
I already mentioned this on other comments, but excessive rewriting could also be a sign of process problems.
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.
OMG we are now using car analogies? Usually, those who drive all day long don't use race cars, but comfortable and clunky things like buses and trucks :-)
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.