For more than a year I have been without syntax highlighting. My editor of choice, acme, simply does not have it and I actually prefer it that way. Some would explain this as an instance of the Stockholm syndrome, or some strange form of hipsterism. However, I think there are some valid advantages to not colouring our texts, and so I will put them forth.
What syntax highlighting is good for
Some people perceive numbers and letters as coloured, and can use this ability to solve some tasks quicker. So initially, giving everyone synesthesia for free using syntax highlighting seems like it should improve our ability to understand code quickly. I do think it does give some speedup in checking wether there are syntax mistakes in the code. The classic example is some sneaky comment errors like this one:
// Initialise
for (i=0;i<3;++i) {
/* Do initialisation here!
niftyConfig = 1;
funkyValue = 2;
}
// Run forever
for (;;) {
/* So, this is where we do stuff! */
...
}Syntax highlighting is not the only way of telling that your parenthesis, quotes and comments are matched up. In Acme I double click on the outmost marker to check that it has a match. This gives the added benefit that the region is selected if I wish to make edits to it. This is an active action on my part, because usually I know where my parentheisis go and do not need any help.
For most part syntax is not the most challenging part of programming, and I have yet to run into troubles where I could not spot my syntax errors. I usually program in a tight loop of writing, compiling and testing, meaning that any syntax related mistakes are probably in the most recently edited region and are easy to spot.
The beauty of code
The first thing one thinks when going from highlighted to unhighlighted code might be «This code is just a grey mash of symbols». Though, this sensation quickly fades as one gets engaged in the code. This “getting in to the groove”-part of the programming session is remarkably short, and afterwards code is more readable than English.
If the code is neatly organised, the «grey mash» quickly crystalises into a beautiful little universe of logically connected parts; each standing by it self, on its own line or in its own scope, but referencing each other in clear and beautiful ways. However, if the code is disorganised, with commented-out code, overly long lines and all, then the «grey mash» shape-shifts to a minefield in rough terrain, with craters and rocks obscruing the view.
What I am saying is that, coding without the syntax highlighting makes me much more sensitive to code “beauty”. This means that I avoid anti-patterns like having too long lines, or commenting out code. When my syntax highligher would make comments grey, I would frequently have two or three versions of a function in the comments while writing, and have to remind my self go clean the mess up. Now, I much rather copy the old version to a scratch file or buffer before making revisions. This keeps the code beautiful and easy to read.
Supports all languages
Once syntax highlighting is gone, you no longer priviledge the class of languages for which there exists a syntax highlighting. As a programmer you will not spend time looking for a highlighter, and configuring it for your preferences. Since I work a lot in a language called Agda, which is a language with absent support in most editors, this is important to me.
Editors in general suffer from over-configurability. Humans in general, and programmers in particular, like to tinker. Once you start tinkering on the configuration file of your editor, it easily gets in the way of what you actually were supposed to do. Syntax highlighting especially invites to these distractions as it is in your face while programming. If something about it annoys you, you are bound to notice while programming.
Supporting all languages equally future-proves the editor, because who knows which language we will use in ten years? Not to mention that syntax in a given language changes between version: new keywords added, new function syntax, and λ-abstractions added.
This also clears the distinction between the editor and other tools. The editor lets you edit code, it does not parse it and check its syntax. If it does, it is bound to do it wrong when the language changes, and require continual maintainance.