I've no problem with syntax highlighting as a concept, but invariably it's only designed for white or black terminal. If you need to use something else, like light gray, then certain colours of elements disappear due to low contrast.
Much like the colour output of ls; beautiful on black, largely invisible on anything else.
I use syntax highlighting, but I use very mellow colors that do not distract. The example given out in Akesson's article is a complete eyesore, however many text editors are like that and it's not that simple to change the color scheme in all of them.
I believe syntax highlighting can also spoil you if that's all you're used to. It is a good exercise to write and maintain some code in raw format, occasionally.
Personally I think it's enough just to highlight the reserved keywords and comments.
Most of why I think it is nutty is because most of the reasons given to support disabling highlighting boil down to "I don't like this particular colorscheme". Which editors make it difficult to customize your colorscheme? All of the popular ones that I know of make it simple. Even nano makes it simple.
My synthesis of the acme/plan9 folks and the mainstream is that color can be useful in an environment, but the way it's currently used is not. Like this guy points out, there's no point highlighting language keywords; we're just doing it because it's easy to do so. Rather conserve the color and our attention for when it's truly needed.
But the need for color seems too strong to fight with pure rationality. Perhaps it's enough that adding a little color to an environment we spend a significant amount of our lives in makes us happy. Since I have no taste, garishness doesn't bother me :)
Hopefully these considerations will be subsumed by new research by Bret Victor or Rune Madsen (http://vimeo.com/61113159).
For now, here's my preferred syntax highlighting, with just a dash of color in most usual places, but two colors for comments: http://i.imgur.com/H1h7M.png. (Why 2 comment colors? http://akkartik.name/post/2012-11-24-18-10-36-soc has the scoop.) Notice how the left pane is C++ and the right pane is my toy lisp, and the syntax kinda harmonizes.
I have little objection to some people preferring fewer colors or having fewer things called out for coloring. What I don't understand is the leap from "This particular scheme is totally overdoing it" to "Let's discard the notion entirely" Merely adjusting the colors that you use and the things that you highlight seems like a clear winning solution.
> there's no point highlighting language keywords; we're just doing it because it's easy to do so. Rather conserve the color and our attention for when it's truly needed.
Yes, highlighting language keywords is like capitalizing or bolding the unstressed words in English:
> there's no point highlighting language keywords;
Disagree, it helps confirm you typed it correctly when you are trying to, and that you've named something incompatibly when you aren't. Thereby very likely preventing syntax/name errors before they happen.
This reminds me of something I've heard Douglas Crockford propose in the past: syntax highlighting would be more useful [in some languages] if it was used to color different scopes.
I already do this in Sublime Text, it's very useful when you may have PHP and HTML in the same file. It's also useful with the much less common HTML with CSS or JS.
I fear you're about to get a lot of comments about mixing PHP and HTML in the same file. And I don't think the OP was talking about that kind of 'scope'.
TL;DR - no syntax highlighting means you have to read the code to avoid syntax errors, and that keeps it more present in your head.
Which is true, we used to joke that the C compiler on a VAX was so slow that you wanted to be really really sure it wasn't going to throw some crappy syntax error so you read through your code twice before submitting it. But a friend of mine from the Amiga community showed me that iterating fast often lead to faster code development than slower iteration. In both cases having your code in your head made for a better result, but someone who could iterate fast and hold the code in their head, always out performed the person on the slow path.
I think turning syntax highlight off is too radical, you can get all the benefits mentioned in the blog post by using colorschemes like zazen or zenesque.
I believe this is worth thinking about, because if the syntax highlight is only to disguise whenever the syntax is incorrect, you could only highlight it when it is incorrect, and modern IDE's (vim including) are capable of doing this.
On the other hand, perhaps highlighting the syntax is to represent the structure of source code, or make it more readable. There is also a text highlight utility for text, called BeeLineReader (http://www.beelinereader.com/)
"The best way I can describe it is to compare it to reading a book. When I read a book, I don't want parts of speech highlighted in different colours. What I want to do is to read the book, to take in the information."
I found this interesting, as my reaction has been almost the complete opposite. I've never felt that syntax highlighting played a part in understanding code at a high level. Syntax highlighting is there for when I'm reading my code like a copy-editor. It (along with an inline linter) is there to make syntactical errors more obvious so I can deal with them as I make them.
I think this analogy is just terrible. A book != code. Well, certainly a novel, in which you're not re-reading the same sentence several times over, flipping 100 pages forward, then 90 pages back, etc. I can actually think of certain ways in which a non-fiction book could be usefully 'syntax highlighted'.
It reduces productivity and adds headache.
Code is not a textbook. A good programmer has to always look at different pieces of code and would lose himself in the mess of symbols if there is no indents and block highlights..
Well, even textbooks often use colors, fonts, emphasis and other mechanisms for the same thing we use it in syntax highlighted code.
And if he's meaning to compare it to prose, while they typically lack color (due more to the means of printing than the format, check out old manuscripts and they use color quite often), they use punctuation and other methods of emphasis like bold, italics, size, and underlining.
I actually sometimes associate words with sound and color - it makes me wonder why we are still limiting ourselves only visual feedback.
I vaguely remember somebody posting a lisp-y emacs-y setup of a synth coding environment of sorts that looked like heaven to me. (You'd quickly iterate on code with transforms that would shift the sound playing at all times and the colors would POP at you) It also makes me wonder how blind coders handle things. Does a pleasant yet distinct background noise when hovering over say, curly braces or parens, does that make sense to anybody else? I'm developing an itch here but I don't want to go it alone as it were.
Edit: also come to think of it, why isn't this stuff empirically tested? The right font faces and sizes for optimal readability, tabs vs spaces, camelCase vs snake_case, colors and which ones, all the classics. Where is the science?
Interesting in theory, though it could get annoying fast (The first thing I do is always to turn off the bell).
Changing tone based on depth could be pretty interesting, as could tones representing things like unused variables.
Based on your preferences, you could also do things like have the noise grow unpleasant if you do something you shouldn't (e.g., reuse a variable name, write an impure function, etc.).
> Syntax highlighting had, for me, been somewhat of a crutch. I was relying on it to immediately highlight code errors
One man's crutch is another man's perfectly reasonable tool. Is a carpenter's level a crutch?
> When I read a book, I don't want parts of speech highlighted in different colours
I have trouble discerning colours and I still use syntax highlighting. I don't think that there are people that are programmers but unable to read code unless all of the floats are purple. The highlighting mostly just tells me "this parsed correctly" and helps my eye track where e.g. string literals begin and end. I don't really see a reason to give either of those things up. If it's distracting, you could easily turn down the theme to just bold one or two keywords and string literals, which solves both of those two problems at least. Maybe go crazy and reverse the background on obvious syntax errors like unexpected symbols.
I rarely want to focus on the code itself and more just want to focus on the problem. Immediately highlighting code errors seems like a perfectly nice thing to do to that end. If I could just write a bunch of code quickly, riddled with syntax errors, and click some magic "okay editor, fix away!" button I'd be fine with that too.
"When I read a book, I don't want parts of speech highlighted in different colours"
I do! In long conversations in novels I occasionally lose track of who is currently talking; normally it's really obvious as the next page of text doesn't make any sense until I backtrack to find where the speech got switched, though one time I finished a whole book where my protagonist had the wrong gender because I didn't realise that the prologue and the main text were written from different people's first-person perspectives...
It also reminds me of some anime fansubs, where series with lots of characters would have each character's subs written in their hair colour, which is really helpful for someone who has trouble disinguishing similar foreign voices from each other :P
It's amazing how often fiction doesn't even indicate the speaker once (in any given dialogue), and just leaps into conversations by simply starting them, relying on context and "voice" to identify the speaker, alternating back and forth with other speakers with no intervening description.
I don't seem to have much problem with this in English, but it causes me no end of grief reading in a non-native language, I suppose because my grasp of context and eye for other cues is much shakier...
[I've read books where I'll get halfway through the book before realizing my entire conception of what's going on has been completely wrong due to confusion over who said something in the beginning of the book... I'll go back, re-read the crucial dialogue with the speakers swapped, and suddenly everything starts making sense... TT ]
> When I read a book, I don't want parts of speech highlighted in different colours
Books don't have syntax highlighting, but having never read a book that does, I can't say one way or the other that it is a terrible idea.
And actually, as I think about it more, books would be a nicer reading experience if conversations were highlighted, and if key person/place names where in a different color.
There is one book I know of which uses text color significantly: Michael Ende's _The Neverending Story_. It's very coarse-grained- the color just tells you whether currently-described events are in Fantastica or The Human World- and I don't know if it actually assists in reading comprehension or anything like that, but it is a joy to read.
As a personal note, the first time I read it, I didn't realize that the colors were significant for a couple of chapters because, for some reason, I occasionally perceive black text on paper as being red, and thus it took me a while to realize that this text actually was printed in red.
And I'd argue that if books did have syntax highlighting, parts of speech wouldn't be the best way to inflect it anyway. Maybe give a colour to each each character, or each location, or even just the subject of a sentence. Which "her" does this refer to? Which speaker is this? These are all potentially valuable things.
And some books do do these things. Often thoughts are italic whereas spoken words are quoted. Pratchett puts Death's words in all caps.
Syntax highlighting is our engineered Synesthesia.
> "The best way I can describe it is to compare it to reading a book. When I read a book, I don't want parts of speech highlighted in different colours. What I want to do is to read the book, to take in the information."
I would love to try reading a book with the same support. Nouns in red and adverbs in green. It would be fantastic! So much passive information available… Now I think I know what my next weekend project is.
Some natural languages capitalize nouns, e.g. German. Japanese uses kanji for noun, adjective, and verb stems, and kana for grammar words and inflections.
Is using <h1> and <h2> tags syntax highlighting for text?
Personally I program Clojure, so there's not a lot of syntax to highlight--well, more than in scheme, for example--but I couldn't imagine life without brace matching (a dynamic kind of syntax highlighting).
Ever since I spent a week wondering why my main loop only ran 3 times, I always turn syntax highlighting on.
This is what my code looked like:
// 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 would have shown the problem instantly. In fact, the bug would never have happened.
Anything that can increase the chance to catch an error is a good thing.
I've found syntax highlighting is good at making the structure of code evident, which in turn makes it much easier to grasp the general idea of a snippet at a glance. This is a very important property!
Code is read more often than it's written, but it's skimmed more often than it's read. So making it easy to mentally jump around code without actually reading it is extremely valuable.
I've found this particularly valuable in Haskell because it lets you use arbitrary things in infix position. Now, this by itself is valuable for the same reason: it helps structure the code, neatly separating the operation from its arguments. Some things just make more sense infix. But visually, it's often hard to grasp when something is infix. This is not too bad with operators:
foo bar baz + qux 11 quux
but it's actually rather difficult with normal words infix:
The most important part of the above snippet is how "using" divides into two clear parts. And yet, on something like HN, this is a bit hard to follow: "using" looks like another word in a string of words--this is exactly what I want to avoid with the infix syntax!
In Emacs, at least, infix symbols--both operators and names in backticks--get highlighted in a different color. This immediately make the structure of the above code completely clear. Then, when I'm glancing through it, I can focus on the part I care about. (This example is particularly appropriate because the two halves do completely different things--the left one defines the computation and the right one specifies how to parallelize it; chances are I only care about one of the two at a time.)
I think that highlighting operators also explains why I've never had any real difficulties with Haskell's "symbol heavy" code.
This could be extended to a bunch of other structural distinctions I care about. For example, when reading Lisp code, I would love to have macros and functions highlighted differently. Macros generally represent some sort of code organization where functions are often part of the actual program logic; moreover, macros and functions behave very differently.
47 comments
[ 3.3 ms ] story [ 109 ms ] threadMuch like the colour output of ls; beautiful on black, largely invisible on anything else.
http://www.linusakesson.net/programming/syntaxhighlighting/
I still think it is nutty.
I use syntax highlighting, but I use very mellow colors that do not distract. The example given out in Akesson's article is a complete eyesore, however many text editors are like that and it's not that simple to change the color scheme in all of them.
I believe syntax highlighting can also spoil you if that's all you're used to. It is a good exercise to write and maintain some code in raw format, occasionally.
Personally I think it's enough just to highlight the reserved keywords and comments.
But the need for color seems too strong to fight with pure rationality. Perhaps it's enough that adding a little color to an environment we spend a significant amount of our lives in makes us happy. Since I have no taste, garishness doesn't bother me :)
Here's an example of color being used in a relatively staid place -- and paying for itself: https://plus.google.com/110440139189906861022/posts/UqyUZdqP...
Hopefully these considerations will be subsumed by new research by Bret Victor or Rune Madsen (http://vimeo.com/61113159).
For now, here's my preferred syntax highlighting, with just a dash of color in most usual places, but two colors for comments: http://i.imgur.com/H1h7M.png. (Why 2 comment colors? http://akkartik.name/post/2012-11-24-18-10-36-soc has the scoop.) Notice how the left pane is C++ and the right pane is my toy lisp, and the syntax kinda harmonizes.
Yes, highlighting language keywords is like capitalizing or bolding the unstressed words in English:
Disagree, it helps confirm you typed it correctly when you are trying to, and that you've named something incompatibly when you aren't. Thereby very likely preventing syntax/name errors before they happen.
Which is true, we used to joke that the C compiler on a VAX was so slow that you wanted to be really really sure it wasn't going to throw some crappy syntax error so you read through your code twice before submitting it. But a friend of mine from the Amiga community showed me that iterating fast often lead to faster code development than slower iteration. In both cases having your code in your head made for a better result, but someone who could iterate fast and hold the code in their head, always out performed the person on the slow path.
It can be hard to develop the discipline though.
* zazen: http://www.vim.org/scripts/script.php?script_id=3413
* zenesque: http://www.vim.org/scripts/script.php?script_id=3340
On the other hand, perhaps highlighting the syntax is to represent the structure of source code, or make it more readable. There is also a text highlight utility for text, called BeeLineReader (http://www.beelinereader.com/)
I found this interesting, as my reaction has been almost the complete opposite. I've never felt that syntax highlighting played a part in understanding code at a high level. Syntax highlighting is there for when I'm reading my code like a copy-editor. It (along with an inline linter) is there to make syntactical errors more obvious so I can deal with them as I make them.
And if he's meaning to compare it to prose, while they typically lack color (due more to the means of printing than the format, check out old manuscripts and they use color quite often), they use punctuation and other methods of emphasis like bold, italics, size, and underlining.
I vaguely remember somebody posting a lisp-y emacs-y setup of a synth coding environment of sorts that looked like heaven to me. (You'd quickly iterate on code with transforms that would shift the sound playing at all times and the colors would POP at you) It also makes me wonder how blind coders handle things. Does a pleasant yet distinct background noise when hovering over say, curly braces or parens, does that make sense to anybody else? I'm developing an itch here but I don't want to go it alone as it were.
Edit: also come to think of it, why isn't this stuff empirically tested? The right font faces and sizes for optimal readability, tabs vs spaces, camelCase vs snake_case, colors and which ones, all the classics. Where is the science?
Changing tone based on depth could be pretty interesting, as could tones representing things like unused variables.
Based on your preferences, you could also do things like have the noise grow unpleasant if you do something you shouldn't (e.g., reuse a variable name, write an impure function, etc.).
Whatever metaphor you use, this is just dumb.
One man's crutch is another man's perfectly reasonable tool. Is a carpenter's level a crutch?
> When I read a book, I don't want parts of speech highlighted in different colours
I have trouble discerning colours and I still use syntax highlighting. I don't think that there are people that are programmers but unable to read code unless all of the floats are purple. The highlighting mostly just tells me "this parsed correctly" and helps my eye track where e.g. string literals begin and end. I don't really see a reason to give either of those things up. If it's distracting, you could easily turn down the theme to just bold one or two keywords and string literals, which solves both of those two problems at least. Maybe go crazy and reverse the background on obvious syntax errors like unexpected symbols.
I rarely want to focus on the code itself and more just want to focus on the problem. Immediately highlighting code errors seems like a perfectly nice thing to do to that end. If I could just write a bunch of code quickly, riddled with syntax errors, and click some magic "okay editor, fix away!" button I'd be fine with that too.
To each their own I suppose.
"How I stopped [perfectly fine activity]... And why you should, too."
I do! In long conversations in novels I occasionally lose track of who is currently talking; normally it's really obvious as the next page of text doesn't make any sense until I backtrack to find where the speech got switched, though one time I finished a whole book where my protagonist had the wrong gender because I didn't realise that the prologue and the main text were written from different people's first-person perspectives...
It also reminds me of some anime fansubs, where series with lots of characters would have each character's subs written in their hair colour, which is really helpful for someone who has trouble disinguishing similar foreign voices from each other :P
Perhaps the actual story narrative needs to be clearer, by repeating the speaker's name more often.
I don't seem to have much problem with this in English, but it causes me no end of grief reading in a non-native language, I suppose because my grasp of context and eye for other cues is much shakier...
[I've read books where I'll get halfway through the book before realizing my entire conception of what's going on has been completely wrong due to confusion over who said something in the beginning of the book... I'll go back, re-read the crucial dialogue with the speakers swapped, and suddenly everything starts making sense... TT ]
Books don't have syntax highlighting, but having never read a book that does, I can't say one way or the other that it is a terrible idea.
And actually, as I think about it more, books would be a nicer reading experience if conversations were highlighted, and if key person/place names where in a different color.
(Just like text in RPGs sometimes).
As a personal note, the first time I read it, I didn't realize that the colors were significant for a couple of chapters because, for some reason, I occasionally perceive black text on paper as being red, and thus it took me a while to realize that this text actually was printed in red.
And some books do do these things. Often thoughts are italic whereas spoken words are quoted. Pratchett puts Death's words in all caps.
> "The best way I can describe it is to compare it to reading a book. When I read a book, I don't want parts of speech highlighted in different colours. What I want to do is to read the book, to take in the information."
I would love to try reading a book with the same support. Nouns in red and adverbs in green. It would be fantastic! So much passive information available… Now I think I know what my next weekend project is.
http://en.wikipedia.org/wiki/Synesthesia
Once you're used to the lack of color, go all the way and use a proportional font.
Personally I program Clojure, so there's not a lot of syntax to highlight--well, more than in scheme, for example--but I couldn't imagine life without brace matching (a dynamic kind of syntax highlighting).
This is what my code looked like:
Syntax highlighting would have shown the problem instantly. In fact, the bug would never have happened.Anything that can increase the chance to catch an error is a good thing.
[EDITED for code formatting.]
Code is read more often than it's written, but it's skimmed more often than it's read. So making it easy to mentally jump around code without actually reading it is extremely valuable.
I've found this particularly valuable in Haskell because it lets you use arbitrary things in infix position. Now, this by itself is valuable for the same reason: it helps structure the code, neatly separating the operation from its arguments. Some things just make more sense infix. But visually, it's often hard to grasp when something is infix. This is not too bad with operators:
but it's actually rather difficult with normal words infix: Now compare this to the highlighted version: http://jelv.is/img/hs-syntax-hl.pngThe most important part of the above snippet is how "using" divides into two clear parts. And yet, on something like HN, this is a bit hard to follow: "using" looks like another word in a string of words--this is exactly what I want to avoid with the infix syntax!
In Emacs, at least, infix symbols--both operators and names in backticks--get highlighted in a different color. This immediately make the structure of the above code completely clear. Then, when I'm glancing through it, I can focus on the part I care about. (This example is particularly appropriate because the two halves do completely different things--the left one defines the computation and the right one specifies how to parallelize it; chances are I only care about one of the two at a time.)
I think that highlighting operators also explains why I've never had any real difficulties with Haskell's "symbol heavy" code.
This could be extended to a bunch of other structural distinctions I care about. For example, when reading Lisp code, I would love to have macros and functions highlighted differently. Macros generally represent some sort of code organization where functions are often part of the actual program logic; moreover, macros and functions behave very differently.