This hardly makes a case at all. Only one section in the middle is actually dedicated to why syntax highlight is bad and it boils down to a baseless assertion about "biasing" the developer's mind toward syntax. I would counter that assisting developers in thinking about how code will be interpreted or compiled rather than bytes of text is closer to the semantic meaning than without.
There's also a comparison to highlight syntax in fiction, which is absurd for many reasons. A simple one being that the _goal_ of fiction can often be to obscure meaning for the sake of ambiguity. I'm offended not by the thesis but by the presumptuous nature of the argument.
I have a strange use case for syntax highlighting: If you ever forget to close a string or a function definition argument list, or anything along those lines, the following text will not be colored as usual. This is also why I have automatic indentation enabled, if the indent is put in the wrong place, I know I made a syntax error further up.
In many (most?) languages, you can look at where your code stops being colored and see you forgot to close something like a comment or a paren.
I don't know about the person you're replying to, but I'm still old school and don't integrate compiling with my editor; maybe some day it will use a language server and get that for free, but for now it's just language specific configuration that does an OK enough job. When I write a string and the rest of the screen is string colored, it quickly notifies me that I messed up something.
Depends on the language, depends on the syntax highlighter. I've seen syntax highlighters that don't make un-terminated python strings look wrong, because the highlighter knows that strings can't span multiple lines (others will give a red squiggly). Some languages give really cryptic errors about the next line -- which gets you in the right neighborhood, good enough for me, but not so friendly for newbies.
It depends on the compiler or interpreter. Some don't give very informative messages and indicate a syntax error on a line that may be one or more lines after the actual error. But the syntax highlighting gives an immediate indication that something isn't right.
Alice
was
not a bit hurt,
and
she
jumped up
on to her feet
in a moment:
she
looked up,
but
it was all dark overhead;
before her was another long passage,
and
the White Rabbit
was
still in sight,
hurrying down it.
I mean, just look at it. Would you read a whole book like this? You can't see the semantics for all the obsession with syntax.
Case against multi-file projects! Would you read a book if you had to go back to a Makefile or other project artifact to figure out where the next chapter is? Come on, put the whole damn program in one file that reads from top to bottom!
Case against local variables:
but
let P = "another long passage"
it was all dark overhead;
before her was P,
and
the White Rabbit
was
still in sight,
hurrying down P
This is now totally unnatural "STEM speak". Use the good old ambigous anaphoric pronouns, or GTFO!
Your first example might actually be really nice in something like a math paper. Something that follows a somewhat rigid premises-argument-conclusion format.
For prose, it's obviously silly, because one point and one goal of prose is to keep the reader in the dark about many wonderful things - or even mislead them to suprise them. So techniques that allow for an easier skimming and back-and-forth (like I did to compare example #2 with example #1) are detrimental there.
While I agree with your argument that the comparison with fiction is nonsensical, I'd actually like to try reading a book like that. I'm a slow reader, and I wonder if indenting based on the structure of the sentence might help me.
This article is very interesting. I recommend everyone who reads this to try and dissect what makes a wrong argument sound convincing.
A ton of terrible arguments are made here: X is important so Y is not important. ABC is a sacred rule that must be followed without question and doing XYZ does not follow the sacred rule. Wrong thing is done to help dumb people so smart people shouldn't do wrong thing.
I'm not actually very convinced by the article, though I don't entirely disagree with it either; I've never been syntax highlighting's biggest fan, and never bothered to tweak it myself. But "the compiler checks it" doesn't mean I shouldn't care about it, and "it doesn't work in fiction" is just totally irrelevant.
The only test is: does it work for you? For a long time, I thought it didn't do much for me, but recently I discovered that highlighting used and unused variables/functions differently helps me find typos, and clean up my code. Comments obviously should be a bit muted. And strings are nice. I don't care much about highlighting keywords, but it doesn't bother me either. I think highlighting the parameters of the function I'm in differently than the rest of my code would help me, but I don't think my IDE does that by default. Maybe it's time to start tweaking my code highlighting.
To me the flaw was "you shouldn't do X in the case of Y therefore you shouldn't do it in the case of Z" the assumption being that Y and Z are similar, but in reality they aren't.
I started programming the C64, then moved to Turbo Pascal 3 for DOS, then Turbo Pascal 6. None of these environments provided syntax highlighting. Then came Borland Pascal 7, with syntax highlighting... And, boy, I was mesmerized!
I really cannot think of going back to plain two-color editors like TP3. Syntax highlighting helps me to spot unterminated strings, mistaken variable names that clash with keywords, plus the general "feeling" of a page of code that I get when I quickly scroll a long source file in search of a specific place.
I do not think that syntax highlighting has spread everywhere just because it looks cool. It is SOOO useful!
Syntax highlighting is more than the article is mentioning, it seems author comment is focused on old highlighters. Once when you get used to one theme brain is not even noticing, unless as shown in example colors are highly offending to aesthetic (the one in the article is hurting my brain). In modern editors as VSCode there is a huge range of adjustments.
Nowadays we can do more than just see what are commands, keywords, increments ... we can see unused variables/import, mistyped variable, see bracket that are not closed, comments, etc.
Independently of anything else, I find the additional distinctiveness created by syntax highlighting helpful for keeping my place, or recognising where I am, if I scroll around a file quickly.
Why on earth would you give up one of the most powerful tools in your IDE? Syntax highlighting speeds up readability, helps write correct code and IMHO, it makes code look pretty.
Color differentials are also a powerful human visual cue. This is why traffic lights are three distinct colors instead of just a top, middle and bottom light.
As to the comparison to prose, well, we have tons of syntax highlighting there too. Capitals at the beginning of sentences. Indentation and spacing between paragraphs, etc.
> Syntax highlighting speeds up readability, helps write correct code and IMHO, it makes code look pretty.
This is a wild claim, and my own experience shows quite the opposite.
For two years, I have been interacting with source code without syntax highlight.
As a result, I feel I am more focused on the content and less distracted. Particularly, that is very noticeable when reading foreign (i.e. other people's) code.
I actually feel that I read slower, but way more attentive. I actually give my brain the time to process the information, and as a result, I get a lot of overlooked bugs that other reviewers don't.
I still find useful, at times, to make the comments in another color, but I noticed that doing so, my brain ignore the comments and a lot of incorrect comments, that could be corrected, went overlooked several times.
Wishing or not, colours are tax your cognition, and for a visual person as I am, they were way bigger distractions than supports: I don't need colours to tell me "for" is a reserved word.
I also find font ligatures very distracting, but it was way more obvious to me that they contribution was negative compared to syntax highlight.
> Color differentials are also a powerful human visual cue. This is why traffic lights are three distinct colors instead of just a top, middle and bottom light.
Well, semaphores have just three elements, which are never shown simultaneously and the colours are well based on semiotics.
That is not the case for syntax highlight.
Syntax highlight seems closer to Stroop test [1] than semaphores.
> As to the comparison to prose, well, we have tons of syntax highlighting there too. Capitals at the beginning of sentences. Indentation and spacing between paragraphs, etc.
Have you looked to a text written in German? That is… Tiring!
In German, all nouns are capitalised. Reading a prose in German LOokS lIkE this TO mE.
I think syntax highlight is the equivalent capitalisation of nouns in prose.
> In German, all nouns are capitalised. Reading a prose in German LOokS lIkE this TO mE.
This is hard to read both because capitalization is a clue that another sentence is starting in English and because uneven multiple capitalization makes it harder to recognize a word. Your brain almost stutters as it pauses to turn the unfamiliar LOokS into looks. Presumably Germans expect the additional capitalization and don't experience this extra processing whereas if you are used to English you are used to deriving different data from more sparsely applied capitalization. While LOokS causes poorer performance for everyone. I think your comparison of highlighting to German capitalization rules is more apt than comparing it to capitalizing random letters.
In keeping with the argument made earlier in the text this ought to improve your understanding of prose because it makes you slow down and really parse it. In reality your brain has a finite amount of processing power and memory and consciously focusing on turning unfamiliar structures into intelligible data and if the data you are taking in is complicated you are taking away resources by being forced to more consciously process it.
You might actually apply this thinking to your experience with syntax highlighting if you aren't used to it you attend to it more so than the data expressed by the code. Your preference and familiarity leads to a different experience than individuals who are used to using it. This doesn't make your preference wrong or right but I question your conclusion that it leads to more attentive reading. I suggest instead that if you discover oft overlooked bugs it is rather because are a more attentive reader rather than being down to reading without syntax highlighting being more effective.
If your IDE didn't use color to indicate syntax, would you want different information conveyed through color-coding? Using color to indicate syntax, which is already directly visible in the code you're reading, does seem like sort of a waste if it could be used to convey more useful information.
Using different colors for sync vs async calls could be helpful. Or pure vs. impure. Or how many times a function or variable definition is used elsewhere in the code base, exercised in tests, referenced in the documentation, etc. I think I would find this sort of non-local information more useful than syntax highlighting.
There was a blog post linked here a couple weeks ago that used color shading to distinguish levels of nested parentheses, with color shift on mouseover, which was interesting.
The article suggests marking "=" and "==" in different colors, which doesn't seem very useful unless the font shows adjacent = characters with no space between them.
There is a mode for Emacs that picks a different color for different identifiers and uses the same color for a given identifier throughout the code to better aid picking out how a given item is used.
I've been programming since before syntax highlighting was common, and I continue to program without it frequently enough that I'm happy to not rely on it. I'd rather spend my time programming than figure out how to get colors working in the terminal session in. What I like is to be able to get work done in any situation. Reliance on any given tool is an impediment to that.
Not to say that I hate syntax highlighting. Likewise: I carry a lighter camping, but I also know how to make and use a bow drill. I think there's a big difference between learning to live without a technology, and hating that technology. And that's the generous read of this article.
To rebut the author, I've seen an indisputably good use of syntax highlighting: rainbow-colored parentheses in emacs. In most languages, I've got a sixth sense for unmatched parens, braces and brackets -- but that isn't strong enough for lisp.
I'd have to add coloring strings and language keywords to the list of exceptions before trying this. Strings are (imo) an obvious necessity, but I can't tell you how many times I've stopped myself from naming a variable a reserved keyword because it showed up visibly differently when typing it out.
I'm generally favorable to giving up syntax coloring. I do agree with the OP that it distracts without adding much benefit. I want to recognize the intent, over the syntax. I do usually program in Lisp/Scheme/Racket, which are syntactically simple though, and use Solarized which is lower contrast than some. So both the distraction and benefits are less.
I guess the main benefit I feel I'm getting now is string highlighting and comment dimming. Parens stand out to my brain anyway so I don't think I am benefitting from their being colorized.
I'm confused. This article is about syntax highlighting, not semantic highlighting. Do you have semantic highlighting set up.or syntax highlighting? If the former, what are are you using?
1 helps with typos , I will notice a weird color and probably underlines if the variable or function is undefined so I can fix the issue before it crashes somewhere in the future
2 also helps me when it highlights unused stuff, shows me that a refactor or a merge happened and it needs a closer look
3 we put JSDoc type documentation and colors will look different if say you used a method on an object that does not have such method or member defined
I create my personalized color schemes that fit me and my disabilities so I don't care if maybe it does not work for someone else or if soem dude tested on some students and observer some small effect or even worse some designer decide how my stuff should look because he read some blog posts from his guru and now he thinks he is a UX master.
I suggest people try a good IDE, tweak things, I always notice bugs in my colleagues code that a good IDE would have prevented them.
Skimming code is a legitimate task. At a large/FAANG company you will often have a 400k sloc code base and only a vague idea which bits of code you need to study more intensively to find out what you need.
One size does not fit all. If you are more productive without syntax highlighting, by all means, disable it.
When I first started to program, I found syntax highlighting annoying and distracting, but I changed my mind within a year or so. So I have tried both sides and made my choice.
I also think that the usefulness of syntax highlighting depends a lot on what language you are using. For example, I found it very helpful when working with Perl, but nearly pointless when writing SQL. Like I said, one size does not fit all.
The problem in the example is excessive contrast that interrupts the visual connectivity of related elements. Stop using party-colored themes and the highlighting is less objectionable
Good point: no-syntax highlighting is just syntax highlighting in one color, with no computation time spent to perform it. What the situation really is is that there are a variety of ways syntax highlighting can be done--not just the colors, but how fine-grained you want to be. Blanket statements like "syntax highlighting is bad" just don't make sense.
This is a very good point. Excessive highlighting can be distracting by itself. I try to keep it to a minimal - colors that are close enough, as well as using bold so that the flow of reading isn't broken.
Also, avoid RGBi colors. They are horrible, period.
colorblind. absolutely hate syntax highlighting. I don't understand how you can read text that changes contrast every few characters - but obviously it looks different for everyone else.
I can't stand syntax highlighting. I mean literally -- I can't read code that is displayed using syntax highlighting, and when someone tries to force me to, I can't understand it. When someone ask for my help with a piece of code, I have to ask them to turn the highlighting off (which in some editors is harder than you think). I normally use acme, which doesn't even have syntax highlighting, but it bothers me to no end that on some (many? all?) Linux distributions vim comes by default with syntax highlighting on. Fortunately BSDs come with nvi, which also doesn't have syntax highlighting.
Unfortunately, most blog posts and documentation on web sites spam syntax highlighting in my face. For those cases I copy the code in my editor to read it which also has the benefit of allowing me to see it with proportional fonts. I use proportional fonts for my programming.
I don't know, I don't think so. I am very sensitive to the color and quality of light, for example I imediately see the metameric failure caused by crappy (99%) of LED lights and I spent months finding some good LED-based lightbulbs.
One hypothesis that I came out with might be that advertising competes for my attention using lots of colors, and I have become very experienced in tuning out any kind of advertising. I don't consciously associate colored text with advertising, but for whatever reason the mechanism seems to be active in my brain.
Sometimes color highlighting actually serves as an objectively beneficial function, for example colored grep output or colored diff output. Even in those cases I still have to turn colors off, otherwise I simply skip past the important bits of the text that are highlighted.
I see past syntax highlighting for the most part- until I need it and then I don't. I don't understand a lot of this "convenience is a crutch" rhetoric around programming. Yes, it's a crutch, but for many of us, maybe even most, it enables us to work on the stuff that matters with more ease.
Syntax highlighting helps reveal structure, so you can understand the whole at a glance, before then zooming in on a part to gain deep understanding. Without the revelation of structure, identifying the parts to go deep on would only be harder.
Syntax highlighting was originally done with typography, not color. Just look at, say, Smalltalk code from the 70s, where italics and bold were used to distinguish syntactic elements. This was also common in academic papers of the late 70s and early 80s as laser printers became more common.
This error helps make the author’s point:
> Maybe it was introduced in order to flatten the learning curve.
The steeper the curve, the easier to learn, so I suppose by flattening it you are deliberately making learning the piano more difficult.
I think you have your last sentence backwards. A steep learning curve is analagous to climbing a steep hill: a gradual climb is much easier than a steep climb.
The author has it backwards. The learning curve, or experience curve, is how manufacturing costs drop and reliability increase as production volume increases. The steeper the curve the better.
I have occasionally heard people get it backwards but I assume they are just copying the term without bothering to learn what it means.
> The common expression "a steep learning curve" is a misnomer suggesting that an activity is difficult to learn and that expending much effort does not increase proficiency by much, although a learning curve with a steep start actually represents rapid progress. In fact, the gradient of the curve has nothing to do with the overall difficulty of an activity, but expresses the expected rate of change of learning speed over time. An activity that it is easy to learn the basics of, but difficulty to gain proficiency in, may be described as having "a steep learning curve".
So the term "steep learning curve" is well-established and my interpretation was correct, but my analogy was wrong. The OP seems to be using it correctly according to the above quotation. "Steep" is a misnomer, but that doesn't make using the term wrong.
It's an unfortunate comment since I struggle with word salad most days. Being able to skim and find certain blocks or aspects of a source file is preferable if I can't remember the name of something right away.
I'm not convinced, but this is an interesting take.
The selected examples are unfair as they use a badly contrasted foreground color against a white background which break all the WCAG Guidelines for contrast. IDEs should use colors with an accessible contrast ratio.
#00dd00 (green) -> #ffffff: 1.85:1 - fail on all results
#00dddd (cyan) -> #ffffff: 1.70:1 - fail on all results
I feel another exception would be the differentiation of static, member and local variables as an additional IDE-based hint, on top of naming conventions.
Um, no. The article's argument, to the extent that there is one, is based on the claim that syntax highlighting natural language doesn't help. But code is not natural language. It is dominated by a small number of common keywords (function/class definitions, for loops, etc) and for these it -- shock! -- is helpful to have them standout visually from the less predictable content.
This is not a very convincing argument at all. Syntax highlighting takes away the mental burden of analyzing the syntax of a program, freeing the programmer to think about the structure and semantics of it. A good IDE (a good vim setup can count too) goes further, making the structure and semantics of a program more easily discerned.
Highlighting also exists to increase edit-ability.
Look at the authors own example, if you want to change the number of iterations in the loop or edit a type, you can do that practically instantly. Does this come at the cost of readability? Perhaps. This is also probably subjective and for the author the cost is apparently too great.
I don't know what it is about programming that churns out these takes about not using effective tools and making things harder on yourself. There's this odd strain of ascetic masochism that breaks out from time to time that I can't say I've observed much in other subcultures.
How do I disable syntax highlighting in JetBrains IDEs? I can choose all kinds of color schemes, but there is no predefined "Plain" color scheme. I would have to create a new scheme and go through each syntax element and reset the color manually.
A point of counter-evidence. Developers seek out syntax highlighting. Perhaps they've all been duped by the hype. Orrrrrrr they actually find it helpful.
Agreed, but structure is prose is important too. Who wants to read something that is not broken into paragraphs, has not capital letters to indicate sentences, etc.
Yeah, but that’s not syntactical structure. When you read prose you aren’t thinking about subject, verb, and predicate, because semantics are far more important.
Some language teaching software does use syntax highlighting for specific lessons. Rosetta Stone at least does, where it specifically highlights things like noun/adjective agreement, verb conjugation agreement with pronouns and names (io pago, capello rosso [italics for highlighting since we can't color text here]). And then we use various types of brackets, bold, italic, dashes and commas, and other things to isolate what we write. If I want to emphasize something, on HN, I use a pair of asterisks around the text: *emphasize*.
We use all sorts of typographical conventions to draw attention to the things we want emphasis drawn to or to encode some notion. In many novels, in English at least, a character's thoughts are italicized rather than quoted. The noir detective might be found at his desk thinking, I knew I'd seen her before, but no name came to mind. In textbooks you have a mix of bold and italics used to identify specific kind of content. Bold for new keywords students of the book should keep in mind, usually adjacent to a definition. Italics might indicate a name assigned to something: Using the pumping lemma we can...
Perhaps in our code editors we've overdone highlighting, or coloring could be a poor (certainly for some colorblind readers) method of highlighting, but syntax highlighting itself can make a great deal of sense.
It's worth considering that in the examples from prose, we usually don't draw attention to syntax, but to semantics. What does the thing with different typography mean, why is it given that special formatting or why is it surrounded by special brackets, dashes, or quotes. We don't highlight (as in the example in the article) nouns one way, verbs another, adjectives a third, and adverbs a fourth. Or verbs different ways depending on the tense or number. We highlight individual words in some manner to bring attention to them, or groups of words to indicate their logical separation in some sense from their surroundings.
It might help identifying arguments. It's a huge cognitive load to identify the premises and the conclusion of an argument.[0] I've seen quite a few philosophers using text markers to help themselves navigate through arguments in prose.
When you’re reading a book out loud to a child one thing that matters is who is talking (so you can do their voice) so colour-coding characters would be nice!
You hit the nail on the head. The author seems to be saying syntax coloring is bad, because you don't do it for prose. But you read code differently than you read prose.
Syntax highlighting also doesn't make you focus only on the syntax. That is just absurd. It actually does the opposite. You actually play less attention to the syntax.
As an experienced coder syntax highlighting makes my job easier
Yeah the logic does not follow that highlighting prose means highlighting code is bad.
I think the main benefit to highlighting code is it’s one less task my brain has to do, freeing it up to think about the structure of the code in writing and the bigger picture.
Searching your code for that our of place ‘ is no benefit to anyone.
>"Syntax highlighting is a standard feature of most modern text editors"
Sorry it was a standard feature in some IDE's like forever. Nothing is modern about it except the fact that the amount of what being recognized and made visually different did increase thanks in good part to language servers.
As for giving it up - well for what I care they could still use punch card, their choice. For me - I would not give it up.
Lots of people here are old enough to remember when syntax highlighting wasn't standard. Also the article itself is old (2007), and syntax highlighting, though common, was not as ancient, standard or varied then as it is now.
I am definitely old enough (60 years). Yes it was not standard in industry say in the 90s and I have to admit I was incorrect in this sense. Still it was available in some IDEs. Like Turbo Pascal had it since 1992.
There's also a comparison to highlight syntax in fiction, which is absurd for many reasons. A simple one being that the _goal_ of fiction can often be to obscure meaning for the sake of ambiguity. I'm offended not by the thesis but by the presumptuous nature of the argument.