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.<p>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.<p>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.
Case against indentation!<p><pre><code> 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.
</code></pre>
I mean, just <i>look</i> at it. Would you read a whole book like this? You can't see the semantics for all the obsession with syntax.<p>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!<p>Case against local variables:<p><pre><code> 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
</code></pre>
This is now totally unnatural "STEM speak". Use the good old ambigous anaphoric pronouns, or GTFO!
This article is very interesting. I recommend everyone who reads this to try and dissect what makes a wrong argument sound convincing.<p>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 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!<p>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.<p>I do not think that syntax highlighting has spread everywhere just because it looks cool. It is SOOO useful!
Some past threads:<p><i>A case against syntax highlighting (2007)</i> - <a href="https://news.ycombinator.com/item?id=11857006" rel="nofollow">https://news.ycombinator.com/item?id=11857006</a> - June 2016 (77 comments)<p><i>A case against syntax highlighting (2007)</i> - <a href="https://news.ycombinator.com/item?id=8606065" rel="nofollow">https://news.ycombinator.com/item?id=8606065</a> - Nov 2014 (2 comments)<p><i>A case against syntax highlighting</i> - <a href="https://news.ycombinator.com/item?id=8262192" rel="nofollow">https://news.ycombinator.com/item?id=8262192</a> - Sept 2014 (3 comments)<p><i>A case against syntax highlighting (2007)</i> - <a href="https://news.ycombinator.com/item?id=7445455" rel="nofollow">https://news.ycombinator.com/item?id=7445455</a> - March 2014 (1 comment)<p><i>A case against syntax highlighting</i> - <a href="https://news.ycombinator.com/item?id=3717303" rel="nofollow">https://news.ycombinator.com/item?id=3717303</a> - March 2012 (24 comments)<p><i>A case against syntax highlighting</i> - <a href="https://news.ycombinator.com/item?id=253114" rel="nofollow">https://news.ycombinator.com/item?id=253114</a> - July 2008 (1 comment)
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.<p>With syntax highlighters can be applied same rule as with UI, pleasing interface make it more usable.
<a href="https://www.nngroup.com/articles/aesthetic-usability-effect/" rel="nofollow">https://www.nngroup.com/articles/aesthetic-usability-effect/</a>
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.<p>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.<p>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.
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.<p>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.<p>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.<p>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.
When I started into computers syntax highlight wasn't even a thing, hence why certain languages use uppercase keywords as way to marking them.<p>For me syntax highlighting hate is nothing more than luddism.
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 have semantic highlighting setup for Rust and I wouldn't give it up. Just way too comfy.<p>"moves focus from content to form", if data drives your code structure, especially easy with functional langs, these two start to become isomorphic.
Most of the help I get in my IDE for JS are<p>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<p>2 also helps me when it highlights unused stuff, shows me that a refactor or a merge happened and it needs a closer look<p>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<p>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.<p>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.<p>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.<p>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
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.<p>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 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.<p>This error helps make the author’s point:<p>> Maybe it was introduced in order to flatten the learning curve.<p>The steeper the curve, the easier to learn, so I suppose by flattening it you are deliberately making learning the piano more difficult.
Douglas Crockford has made a similar argument. <a href="https://www.crockford.com/contextcoloring.html" rel="nofollow">https://www.crockford.com/contextcoloring.html</a>
(2007)<p>I'm not convinced, but this is an interesting take.<p>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.<p>#00dd00 (green) -> #ffffff: 1.85:1 - fail on all results<p>#00dddd (cyan) -> #ffffff: 1.70:1 - fail on all results<p>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.<p>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.
For emacs, I recommend the 'almost-mono-themes' package [0]. It supports syntax highlighting without making your editor look like Mardi Gras.<p>[0]: <a href="https://github.com/cryon/almost-mono-themes" rel="nofollow">https://github.com/cryon/almost-mono-themes</a>
Extraordinary.<p>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.
This is why <a href="https://play.golang.org/" rel="nofollow">https://play.golang.org/</a> has a simple layout with no highlight syntax :)<p>* based on Acme <a href="http://acme.cat-v.org/" rel="nofollow">http://acme.cat-v.org/</a>
This inspired me to:<p><a href="https://github.com/DigitalMars/med/commit/adcc084e21427236957a7f94f3547b22a89c7c1c" rel="nofollow">https://github.com/DigitalMars/med/commit/adcc084e2142723695...</a>
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.
Bold claims + no-evidence<p>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.<p>Without more evidence, I'm going with #2.
Needs an old year in the title (2007?).<p>In 2007, I might have agreed.<p>In 2021, I've added syntax highlighting to my own editor (and things feel harder without it).
The comparison with prose is pure nonsense.<p>Syntax highlighting is about understanding structure.<p>I could blur out my editor to the point where I could not make out individual letters and still understand the code structure.<p>When reading prose you don’t care about structure, especially not in English (in latin languages structure is way more important).<p>It’s important to have a good highlighter though. STM32cube IDE has a very bad highlighter that gets confused sometimes.<p>I’ve seen people chasing simple bugs for far too long just because the highlighter was broken.
>"Syntax highlighting is a standard feature of most modern text editors"<p>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.<p>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.