Dear Editor
Machines should work. People should think.
— Richard Hamming
Dear Editor,
I know that you are nowadays often taken for granted, and that many programmers consider you a relic of an older age. Yet, programmers continue to spend an inordinate amount of time with you, and often listen to your advice. As you have no doubt observed I am often mistreated; in this letter I have written my most common grievances hoping you can convince them programmers to behave better toward me in the future.
I know that in the past your position was a lot more important. Developers used to fight over which of your two cousins vi and emacs was the most versatile. Creating an editor was a no mean feat; the (now famous) programmers who brought your cousins to life, Bill Joy and Richard Stallman, had to overcome the limitations of a small address space, slow terminal lines and CPUs, as well as the idiosyncrasies of the numerous mutually incompatible terminals. Today, the pervasiveness of GUI libraries, fast processors, and the abundance of memory space, make the development of an editor a weekend project.
Yet you are not less important than you were 20 years ago. One of the best things you can do for programmers (and, incidentally, us programs) is to convince them to use their head, taking advantage of your advanced facilities, instead of their fingers. This switch will first of all reduce their risk of suffering from repetitive stress injury (RSI). If they can accomplish the effect of 100 keystrokes by giving you a 20 character search and replace command, they have saved their fingers from the impact force of 80 keystrokes. Furthermore, by devising complex commands, instead of repetitively typing, they remain attentive, rather than bored, and, frankly, I trust you a lot more than the programmers in performing repetitive actions. Finally, and most importantly, each time programmers think of the way to automate a complex editing task by giving you an appropriate command they sharpen their mental skills. In contrast to their finite typing capacity, their mental skill appear to be infinitely expandable; over the years I have encountered some programmers who were appearing to perform magic with their editor.
My dear editor, let me give you some examples of how expert programmers let their brain work instead of their fingers. If one of my methods contains variables x1, y1, x2, y2, a deft programmer using Eclipse will look for any of them using the regular expression \b[xy][12]\b (match a word boundary, one of x or y, followed by a 1 or 2). Changing the variable names by adding an underscore in-between the letter and the digit is a bit more complex, but this is exactly what I mean by thinking instead of typing. Programmers using vi would type :s/\<\([xy]\)\([12]\)\>/\1_\2/g (substitute a word consisting of x or y, followed by 1 or 2 with the first matched pattern—\1—, followed by an underscore, followed by the second matched pattern—\2). In some cases where a regular expression-based substitution command becomes too complex, a useful pattern I have seen used involves searching for the code element using a regular expression search, but performing the replacement using the editor's "repeat last command" feature.
Of course, we both know that an editor is not always the perfect tool for modifying programs. External tools can also come handy, and for this I really appreciate editors that can pipe a range of my body through an external filter. For example, if the order of two elements is reversed in a structure, the initialization data can also be reversed by piping it through the awk {print $2, $1} one-liner.
I do not however consider all automation beneficial. Many programmers use your auto formatting facilities to beat us programs into shape. This is however highly inconvenient for us. First of all, your auto-formatting facilities are not a substitute for good taste. Often, by judiciously adding some space in one of my code blocks I can become easier to understand and maintain. The blind application of auto-formatting can destroy carefully laid out code elements. In addition, every time I pass through a version control system with a new format, thousands of unimportant changes are logged, confusing the programmers that will maintain me in the future. Finally, auto-formatting introduces another problem into the development process; a risk-analyst would call it overcompensation. Programmers, confident that you, the editor, will handle all the formatting tasks for them completely neglect formatting us programs, leaving us in a state worse than one we would be without your help. Scientists have observed this phenomenon in the real world: after the introduction of safety caps in medicine bottles parents neglected locking medicine cabinets and accidental child poisonings actually increased. About a week ago I overhead with horror a programmer commenting that he didn't precisely know Java's formatting guidelines, because his editor was handling formatting for him.
I hear you say: "you are asking me to stop doing my work. I simply can not sit idle watching the programmer hack you programs to death!" My dear editor, don't worry, there is plenty of useful work you can do. Syntax coloring is one important function. Through syntax coloring programmers can easily identify keywords, variables, constants, and comments. They can often also spot silly syntax errors (such as a missing quote), avoiding the distraction of an unproductive compile-edit cycle. This brings me to another useful service you should be providing: error highlighting. Identifying a missing operator or semicolon, will also help in the same way, as long as you do it in a correct and unobtrusive manner. Don't distract programmers with false alarms while they write a statement, and never highlight errors that aren't. False error reports will make programmers simply switch this useful feature of yours off. A deep understanding of the language we're written in will also help you better serve programmers. Most modern languages follow a block structure identified by indentation; in some languages (such as Python, Occam, and Haskell) indentation is even semantically significant. An editor that will not allow programmers easily increase and decrease the indentation level of our code blocks, is simply not suitable for programming. Another language-specific service you can offer is the marking of matching delimiters (brackets, braces, square and angle brackets, and, dare I suggest it, XML tags). Of course, I know that some of your kind go even further and provide complete refactoring support: changes of variable names and method signatures, field encapsulation, the extraction of local variables and constants, and movement of my code elements. I am all for that; things that can be done automatically in a reliable way, allow programmers to spend more quality time with me.
You as an editor, should also help programmers navigate within their increasingly complicated environment. By providing on-line help for API elements and convenient facilities for browsing my code's structure I can be less fearful of growing fat and ugly by programmers who will reinvent the wheel instead of using an API feature or one of my existing classes or functions.
I feel I've been babbling for far too long, so I will close this letter with a few words on a facility I am sure you are really proud of: editor macros. I am sorry to tell you, but from my experience, these macros are often signs of a hidden design deficiency. If a programmer has to use a macro to change a program's configuration setting, then the program is not flexible enough. I've observed that in most cases where programmers use macros to save repetitive typing, they are programming at the wrong abstraction level.
So, dear editor, please try to impart to our programmer friends the following advice: don't type what you can automate in the editor environment, and don't use the editor facilities for what you can code.
Sincerely,
A Program
* This piece has been published in the IEEE Software magazine Tools of the Trade column, and should be cited as follows: Diomidis Spinellis. Dear Editor. IEEE Software, 22(2):14–15, March/April 2005. (doi:10.1109/MS.2005.36)
Read and post comments
