"Perhaps syntax highlighting was invented to speed up the reading process.
...
Well, no. One of the basic rules of thumb in typography is that, when writing a piece of text, you should choose one typeface and stick to it"
and then believe the rest of the article. Well, I don't believe that part, since I experience the complete opposite every day. A silly typographical guideline doesn't affect my experience at all.
Semantics are more important than syntax, sure. But it doesn't matter what the semantics are if you screw up the syntax, which you will be more likely to do without syntax highlighting because you're a hairless ape.
I just don't see an actual reason not to use it, but if you don't want to, knock yourself out I guess.
>Well, no. One of the basic rules of thumb in typography is that, when writing a piece of text, you should choose one typeface and stick to it. Likewise, a splash of colour may grab the reader's attention, but it will inevitably decrease the legibility of the text. The natural flow of the text is broken, and it takes more brain effort to piece together the individual letters into words and semantics. Cognitively, the reading process becomes slightly less automatic and slightly more conscious; leaving less room in the conscious part of the mind for actually understanding the text.
That might be true for text, but I don't read code at all the way I read prose. I highly doubt i've ever read more then four or five lines of code in a row without my eye jumping to other parts of the function, forward to the next part to understand why variables are being set up, or backwards to remember when such variable was defined, or jumping to the big picture to remember how this function or that fits into the overall program. Syntax highlighting is enormously helpful to my eye when reading in that manner.
Except the article is not an opinion piece. The author makes a factual claim that removing syntax highlighting makes the code ironically easier to read. That's something that could be measured and either confirmed or refuted in a lab.
For some of us, syntax highlighting DOES make code more difficult to read. We're all different.
I learned most of what I know on a Solaris 9 machine on a CRT with a model m back in 2008 with zero syntax highlighting, in vi and without vim. Zero fluff. I've tried syntax highlighting, but every time I do, I end up going back and my code quality and readability improves. I imagine a similar effect would happen to others if their colors were changed to incredibly tacky colors.
>Do you rely on syntax highlighting when developing software? If so, you may be shooting yourself in the foot. In this post, I will argue that syntax highlighting, while aesthetically seductive, moves focus from content to form, and discourages those who look at the code from trying to understand it.
The very first opening line is an argument against syntax highlighting. Arguments (at least, of this sort) should be based on facts or studies, or at least logical reasoning and it is not introduced as an opinion piece, but an argument.
I only gave the article a glance and I take two issues with it.
>Syntax highlighting applied to fiction. It's easy to spot all the verbs, but why on Earth would you want to do that?
I wouldn't need to for English, however I can think of a situation where I'd like to see the difference between an int '5' and a string '5' at a glance. In fact - that sort of bug isn't all that uncommon in languages that aren't hard typed.
>[misguided piano teachers, yellow keys]...but do they honestly believe that children are unable to learn note names? They will have to, eventually, and then they will have to un-learn the colours.
This argues like a case against mnemonics as learning devices. Mnemonics are an entire memory trick designed to be "un-learned" by the learner. Planet names aren't difficult to learn but a sentence like "Mercury Viewed Earth’s Many Aspects Joyfully Sitting Under Neptune" sure makes the order from the sun easier to remember. Mnemonics are a pretty well-research thing and they work [0]. Most people who want to compete in memory contests rely on using them. My favorite example is the Major System [1].
He's making arguments against it, yes. But he's not saying it as a piece of fact. I can see why you think that, but it's still an opinion piece.
For me, syntax highlighting is a crutch that I want to avoid. I find myself glancing at my code rather than actually reading my code when it's enabled. It's an incredibly refreshing feeling to turn it off and just go back into vi. My code becomes shorter, easier to read, faster and much easier to maintain.
I do all the time. I spend a significant portion of my time using Jupyter, which has syntax highlighting and other 'improvements'. I really dislike it. Then again, I'm within a shell in tmux all day, so...
You're ordering everyone in the thread to stop saying the article is wrong. How can you not expect downvotes?
Setting that aside, though, the author is not just expressing his opinion. This piece isn't saying, "Well, personally, I don't like syntax highlighting." The OP is arguing for a general truth, not just a personal preference of the author. The piece makes objective claims about the effects syntax highlighting has on its users. Why shouldn't people feel entitled to say the argument is flawed if they see flaws in the argument?
I don't really think a sentence as flippant as that one can be considered "ordering"... and it if does, then I order you to stand up for your opinion with words, rather than downvotes.
Really, I just think the guy's just very opinionated and is expressing something that's very important to him. Principle of charity and all that.
Mods - is this kind of downvoting really warranted for these series of comments? I don't really understand. Much more off-topic posts that've been removed from the main thread in the past. Why is this any different?
Also a lot of the time you are ignoring things like int or float because it isn't helpful unless the algorithm specifically needs it. So you read the declarations and just ignore everything after that as the color gives you a clue not to read 'for' for the billionth time.
Absolutely. Syntax highlighting for me is much more about what not to read than it is about what to read. It can be skipping over 'for' for the billionth time but often it's also reading only a couple key tokens to get the gist of what the line does and only going back to read it in full if non-obvious details matter.
> It's easy to spot all the verbs, but why on Earth would you want to do that?
The big difference between genuine reading and coding is the variability of scanning / focus. When you read, you usually want to take it all in -- it wouldn't make sense to jump around because it's a single, linear journey.
Code does not observe this rule, so the more experience you get as a coder, the better scanner you become. You quickly view a class and think "ah yes yes.. it's _roughly_ doing this.. that" -- you sure as heck don't read the whole thing carefully word by word! The best coders are amazing scanners -- capable of pointing out a missing parenthesis in a sea of parenthesis. This argument against syntax highlighting is like taking the batteries outta our flashlight. Sure, we'd be more careful but our productivity would surely suffer.
I want you to know this comment is every bit as subjective and "not helpful / convincing" as you think mine is except mine had deductive reasoning -- yours is just anecdotal. I only been coding for 10 years, so maybe some veterans who been coding since the 70s can share their experience and we can weigh it against yours.
I also question that you indeed are a faster scanner. Here's a specific example I wonder if your scanning would win out on -- Xcode turns internal Cocoa classes blue whereas your own classes are green. You quickly know what you coded and what you didn't. Not helpful? Should already know? I wonder if you inherited someone else's code base if you would enjoy the green immediate feedback rather than the inference you would otherwise have to take.
I've been working for ~8 years in a mix of environments, some with syntax highlighting and some without.
When working without highlighting, I rely on the shape of the code's text and the search function of my editor to navigate as I jump around code. With syntax highlighting, I have those tools, and extra navigational cues provided by little islands of color.
I haven't noticed a difference in my scanning speed or code comprehension between the two. It may be there, but I'm not conscious of it. Consciously, I've got a slight preference for the colorization. It makes the code feel "friendlier", and I'm happier to be looking at it. The un-highlighted environments tend to be older Unix machines with other annoyances in the operating experience, so I'm sure that plays a lot into my perception.
Some human languages actually work this way though. Nouns are always capitalized in German (not just proper nouns as in English). This is sort of a "syntax highlighting" in a way. Actually tying it to programming languages, the reason why some older languages made keywords mandatory upper case was to make them easy to spot in a listing before editor syntax highlighting was a thing.
Heh. The example of highlighting = vs == different just proves the value of syntax highlighting for me. Misspelling keywords is the same thing, a highlighting (or lack thereof) can alert you to the fact that you flubbed the spelling, and save you from a compile or runtime error.
Programming language keywords are different than English verbs. If you misspell keywords, your program will fail, but if you misspell a verb in an essay, nothing catastrophic happens, most of the time.
It does take me longer to read code in an uncolored ssh window than in Sublime with syntax highlighting, that's true. And I agree that semantics are more important than syntax. But I'm not sure I buy that having highlighting makes reading colored code slower than it would be otherwise. The case here didn't present evidence that it's worse. It might be a crutch, but it's also possible that the reason reading uncolored code is slower is because having syntax highlighting is actually better than not having it.
Misspelling a keyword is a low-cost issue. The compiler will point it out to you immediately, and compilers are very fast these days. Nothing happening here is very catastrophic.
Having a compile fail is catastrophic, not in the sense of the amount of effort it takes to fix, but in the sense that the computer has completely rejected your input. Your compile or execution failed. It won't work without change.
Misspelling English doesn't usually cause a complete failure, or force you to try again, that's my point. The example in the essay was a cute comparison that I think actually is worth considering, but is ultimately comparing apples to oranges.
But, no matter how fast your compiler is, the cost of finding and fixing a mis-spelling in your editor with syntax highlighting is much less expensive than finding them and fixing them with a compiler or by executing the program. Could be a few seconds per typo less expensive, but my professional experience has generally involved builds that take 1-10 minutes. I'll take the syntax highlighting crutch over waiting for my compiler to fail.
Compiler errors are much better than the alternative: a run-time bug that won't manifest itself until you put the program under the correct conditions for failure. Compile-time errors are something that programmers have added to compilers to make programming easier/safer because the alternative is truly catastrophic (accidentally shipping broken software and having to isolate more bugs by hand).
I'm not really arguing against syntax highlighting, just saying that this argument for it isn't so black-and-white. Keep in mind that there are many issues syntax-highlighting can't catch that your compiler can (unresolved identifiers, using the wrong function, or accidentally choosing the wrong keyword).
The fastest I've ever seen clang compiled, with ccache and in memory fs, was 7 minutes - which is a long time for a syntax check. Just browse any buildbot dashboard. You could use libclang for interactive evaluation - but boy does it suck when the file that you're working on pulls in a page of headers. What you're suggesting is fine for anything that results in an executable named a.out, but it doesn't work for non-trivial software projects.
Misspelling the keyword happens relatively early in the compiler pipeline (during parsing). If your build hasn't changed very significantly (i.e. something along the magnitude of <1000 lines changed that aren't scattered across tons of files) it should warn you within a few seconds. Anything else is a failure in the design of the compiler or build system. (In fact, outside of C or C++ compilation is usually much, much faster than what you cite). Non-trivial projects in better-designed languages can easily take a tiny fraction of that time.
> If your build hasn't changed very significantly...
Change one character in one file that gets linked at the end of the build, the syntax check would go from 7 minutes to 3.5 on average - still too slow. You're also overlooking conditional compilation, your change might break the build on another platform - the syntax won't be checked until it hits the buildbot that flips the right flags.
> Non-trivial projects in better-designed languages...
Ah, the lets redo-everything-in-x school of thought - good luck with that.
I've not found the Alice-in-Wonderland analogy colorizing the "verbs" to be convincing.
With human language like English, we learn it and use it without the formal grammar++. A 5-year old child can speak to her mother ("I want some candy!") without conscious knowledge of "verbs" or "nouns". A formal grammar for categorization is what we layer on top of language for analysis in school. Two people can communicate and understand each other without any exposure to any grammar lessons. So yes, colorizing verbs looks superfluous and noisy.[2]
On the other hand, computer programming syntax starts with grammar. You learn that certain specific tokens are "data types" and other tokens are "literals", etc, etc. And that grammar categorization in programming languages never goes away as you're typing out new code. (Otherwise, you'd get a compiler error or unintended behavior because x="3"+"5" with quotes ("35") means something different from x=3+5 without quotes (8).) This is why so many experienced programmers find color highlighting helpful even if they've been programming that language for 10+ years. Sure we want to focus on higher cognitive purpose of "semantics" but the grammar is deeply intertwined with reconstructing what the semantics is.
A closer analogy of color highlighting in a different realm would be different colors in TCPIP traces such as "red" highlighting external ip addresses. This can be helpful for forensics of malware phoning home.
Or in financials dashboards where uptrends are "green" and downtrends are "red".
The same reasons that colors help the malware analyst or stock trader quickly parse data at a glance is also how it helps programmers.
++ (at least not consciously that a 5-year old would be self-aware of it. A theory of innate universal grammar in the brain by Chomsky isn't what I'm talking about.)
For me syntax highlighting is almost exclusively to reveal my syntax errors and in that respect is a godsend. This article doesn't resonate with me at all.
Syntax highlighting is helpful to me for the following purposes.
1. Scanning through code.
2. Making it clear what is a comment, what is a string, and what is code.
3. Catching a variety of minor syntax errors automatically. (For example failing to properly close a multi-line quote...)
4. When switching languages, reminding me when I didn't fully switch gears and wound up using the wrong keyword.
I learned to program in vi without syntax highlighting. Before I tried syntax highlighting, I thought it was silly. After I tried it, I found it made for a more comfortable environment. The difference isn't huge, but it is noticeable enough that now I always turn it on.
I have a similar experience. I learned to program as a kid with BASIC (no editor). I learned to read code while I was young because I was too lazy to type the BASIC games found in magazines, so it was easier to parse the game and play it in my mind. I cut my teeth on the MudOS platform, using the in-game `ed` to for rewriting backend code. I didn't use syntax highlighting for a long time.
There are times when I log into a system to edit something with vim, and no syntax highlighting appears. It surprises me, but not a deal-breaker.
I also thought syntax highlighting was unnecessary. The first time I saw a video of using the Twilight theme for Sublime, I was stunned by what the colors brought out. At that time, my awareness was not as developed, so I couldn't even tell you I liked it because of how I experienced the code.
So I spent a lot of time finding good themes for my editors, first vim and now spacemacs. If I am going to look at code all day, I don't want my eyes to bleed. Aesthetics is the strongest argument I have for syntax highlighting, and it should not be casually dismissed without investigation.
Aesthetics matters a lot. Here is a simple example. Light text on a dark background tends to be more readable, but may depress some people. Dark text on a light background is the opposite.
I think there's a middle ground here. Most syntax highlighting uses extremely saturated clashing colors. The feeling you get for the "texture" of the code is useful, but it can make the code hard to read all at once. Using a more toned-down theme brings back some of that legibility without giving up the benefits of syntax highlighting.
I you are using an "Angry Fruit Salad" color scheme, like the example in the article, it's yer own damn fault for not investing 10 minutes to find something more sublime.
Best color scheme I have found, I use it for everything. I can't even imagine opening up some of my code in notepad or vi(m) with no syntax highlighting and actually trying to do a productive amount of work. This suggestion seems absolutely ridiculous if your syntax highlighting is sane.
> Most syntax highlighting uses extremely saturated clashing colors
Really? Why is it then that we have such popularity in color schemes like Solarized[1]? Or the much older zenburn? I'll agree that there are a lot of bad color schemes out there, but that's because anyone can create a color scheme. There's no certification process to create one.
Back in the era where people "themed" their window manager (GNOME, Kwin, Windows, and even OSX had hacks for this), look at all of the really gaudy window themes that were created. Is this an argument against all theming of windows?
Is judicious use of Comic Sans an argument against fonts? Of course not.
Every time I have accidentally started my editor without syntax highlighting due to a misconfiguration (e.g., the file doesn't have the right extension), it has impeded my understanding.
I will take that experimental data over a pile of arguments from first principles any day.
I think that comparison between text and code is wrong! Totally! But maybe it depends how you experience code, it makes sense that it affects your preference to syntax highlighting. And I do not like how he took personal preference and tried to generalize it. If something works for you, doesn't mean it will work for everybody, nor that it can be scientifically true. I know what OP wanted to say, but I think we should stop with those deep minded subconscious thinkings that affect our code.
I like syntax highlighting it, it helps me. Not some over the roof-rainbow colors, I always like minimal and dark color schemes, but I think it would definitely feel weird to code without syntax highlighting. Although I would get used to it. But if it ain't broken don't fix it.
I think comparing text and code actually makes perfect sense but you have to compare the right text.
Pick up any reference book. A dictionary, a textbook, a phone book, whatever. Leaf through it a bit. You'll find they all use text formatting to highlight things. The dictionaries I've used typically use bold for a word and its different forms, italics for parts of speech, and such. Phone books similarly use different weights and sizes for names, addresses, and phone numbers. Textbooks use bold and italics to highlight important terms and concepts and students will often mark up the books to further highlight certain things.
Code is usually not meant to be read like you would a novel; it's much more like a reference text. For me, at least, syntax highlighting is a tool that supports the ability to more easily find what I need and understand it in isolation. Maybe it would be slower for me to read a syntax-highlighted file token-by-token end-to-end than an un-highlighted one but that's not a use case I ever need.
I have to agree with you on that! My bad that I didn't specify what kind of text I was refeering to! I thought of example that was provided in the post.
Definitely iconoclastic, but Linus is also insanely good at what he does, so I wouldn't be so quick to dismiss that position, there might be something there.
But as many others have pointed out, his comparison between code and prose is completely absurd and shows a complete lack of understanding of what he's writing about. He's not actually writing about code, he's writing about both cognitive science and visual design, which I do not believe are his strengths.
Taking a guideline for prose and misapplying it to code does not result in a meaningful insight. Just look at non-prose typeset works such dictionaries, we often see a selection of different font styles there to help the reader scan non-linearly. Look also at newspapers, again we see different font styles, sizes and weights to help the user navigate a page. Look at the references section of an academic paper - you'll find bold italic and underline all used on the same line. Color is very expensive to use in printing prose and so is generally not used, but in handwritten medieval documents color was often used:
Also this claim isn't even correct - code which varies in color is not changing typeface! Really it's no different from using bold or italic in traditional prose, which nobody would complain about.
I learned to code without any sort of syntax highlighting or autocomplete features. Whenever I need to use an editor that has Features like syntax highlighting and autocompletion, my workflow actually slows down pretty substantially. The negatives just don't beat the positives for me.
Why the negative comments with some folk even calling this guy wrong on an opinion piece? Sheesh, people..
What people usually get wrong about text and typography is that there is not just one type of text, and therefore not just one type of typography. Dictionaries have different typography from recipe books, which are different from math books, which are different from newspapers and so on. So saying that source code should not have its own kind of typography because it wouldn't work for some other textform is like saying that encylopedias should be like novels because it would be silly if there were arrows in front of words in novels that appear somewhere else in the book.
Most of the time when you "read" code you explicitly want to parse form and skim over thousands of lines to get a gist of where to drill down. All the anti arguments on this article almost show a complete inverted understanding of common requirements.
This whole article appears to be based on a misunderstanding (or at least an idiosyncratic view) of typography.
Varying styles within a work can be immensely helpful, and is almost universally done. For example, headers tend to be written bigger to indicate a) that they're something different from the main text, and b) what their relationship to the main text is. Similarly, italic and bold text are used to impart additional meaning to various parts of the text. Many publications will use a different style for things like bylines and photo captions — again, because they are different things from the body text and this helps the reader pick out the parts of the page in a purely visual manner. It's even common to see parts of the body text stylized differently to indicate that they have a special function — for example, in a Q&A format, you'll often see the questions formatted differently from answers, or the identities of the speakers might be written differently from the words they said.
So not only is this philosophy about typography not necessarily applicable to code, it's not even widely accepted for ordinary written text.
>Developing software is complex and error-prone, so people need to be thinking when doing it. And yeah, I realize that these opinions are controversial to some.
I agree. However, I don't see how syntax highlighting necessarily makes reasoning code easier or harder. I don't know if the arguments are specious, but I think and feel that much of the arguments in the article are weak and unconvincing.
The author has already dismissed (without examination) the strongest argument for syntax highlighting: aesthetics. There are whole philosophies of aesthetics that makes a lot of sense, but only when we go beyond the mere results of the programming. The aesthetic argument for syntax highlighting isn't for the sake of the quality of the resulting program but rather, the quality of the experience for the programmer. That in and of itself is underestimated by a fixation on the resulting code.
There are philosophies that precisely define aesthetics, but these are generally in the non-dual philosophies, not the dualist philosophies. As soon as you have a dualist philosophy, you set up an opposition between privileging objective over subjective, or subjective over objective, and it resolves nothing. Non-dual philosophies do not privilege objective over subjective, or subjective over objective, and have a lot of useful, testable (empirical, experienceable) things to say about aesthetics.
Aesthetics bring a human perspective to the technology and reminds us that, however efficient a technology is, it shapes and is in turn shaped by our experiences as human beings.
78 comments
[ 3.6 ms ] story [ 140 ms ] thread"Perhaps syntax highlighting was invented to speed up the reading process. ... Well, no. One of the basic rules of thumb in typography is that, when writing a piece of text, you should choose one typeface and stick to it"
and then believe the rest of the article. Well, I don't believe that part, since I experience the complete opposite every day. A silly typographical guideline doesn't affect my experience at all.
I just don't see an actual reason not to use it, but if you don't want to, knock yourself out I guess.
That might be true for text, but I don't read code at all the way I read prose. I highly doubt i've ever read more then four or five lines of code in a row without my eye jumping to other parts of the function, forward to the next part to understand why variables are being set up, or backwards to remember when such variable was defined, or jumping to the big picture to remember how this function or that fits into the overall program. Syntax highlighting is enormously helpful to my eye when reading in that manner.
It's an opinion piece, but you and just about everyone in this thread is writing as if their opinion is a fact that trumps his opinion. Stop that :(.
Edit: Why the downvotes? Are different opinions really that bad?
I learned most of what I know on a Solaris 9 machine on a CRT with a model m back in 2008 with zero syntax highlighting, in vi and without vim. Zero fluff. I've tried syntax highlighting, but every time I do, I end up going back and my code quality and readability improves. I imagine a similar effect would happen to others if their colors were changed to incredibly tacky colors.
The very first opening line is an argument against syntax highlighting. Arguments (at least, of this sort) should be based on facts or studies, or at least logical reasoning and it is not introduced as an opinion piece, but an argument.
I only gave the article a glance and I take two issues with it.
>Syntax highlighting applied to fiction. It's easy to spot all the verbs, but why on Earth would you want to do that?
I wouldn't need to for English, however I can think of a situation where I'd like to see the difference between an int '5' and a string '5' at a glance. In fact - that sort of bug isn't all that uncommon in languages that aren't hard typed.
>[misguided piano teachers, yellow keys]...but do they honestly believe that children are unable to learn note names? They will have to, eventually, and then they will have to un-learn the colours.
This argues like a case against mnemonics as learning devices. Mnemonics are an entire memory trick designed to be "un-learned" by the learner. Planet names aren't difficult to learn but a sentence like "Mercury Viewed Earth’s Many Aspects Joyfully Sitting Under Neptune" sure makes the order from the sun easier to remember. Mnemonics are a pretty well-research thing and they work [0]. Most people who want to compete in memory contests rely on using them. My favorite example is the Major System [1].
[0] https://en.wikipedia.org/wiki/Mnemonic
[1] https://en.wikipedia.org/wiki/Mnemonic_major_system
For me, syntax highlighting is a crutch that I want to avoid. I find myself glancing at my code rather than actually reading my code when it's enabled. It's an incredibly refreshing feeling to turn it off and just go back into vi. My code becomes shorter, easier to read, faster and much easier to maintain.
Setting that aside, though, the author is not just expressing his opinion. This piece isn't saying, "Well, personally, I don't like syntax highlighting." The OP is arguing for a general truth, not just a personal preference of the author. The piece makes objective claims about the effects syntax highlighting has on its users. Why shouldn't people feel entitled to say the argument is flawed if they see flaws in the argument?
Really, I just think the guy's just very opinionated and is expressing something that's very important to him. Principle of charity and all that.
The big difference between genuine reading and coding is the variability of scanning / focus. When you read, you usually want to take it all in -- it wouldn't make sense to jump around because it's a single, linear journey.
Code does not observe this rule, so the more experience you get as a coder, the better scanner you become. You quickly view a class and think "ah yes yes.. it's _roughly_ doing this.. that" -- you sure as heck don't read the whole thing carefully word by word! The best coders are amazing scanners -- capable of pointing out a missing parenthesis in a sea of parenthesis. This argument against syntax highlighting is like taking the batteries outta our flashlight. Sure, we'd be more careful but our productivity would surely suffer.
Feel free to keep doing what you're doing, but making assumptions about workflows that you're unwilling to try is not helpful or convincing.
I also question that you indeed are a faster scanner. Here's a specific example I wonder if your scanning would win out on -- Xcode turns internal Cocoa classes blue whereas your own classes are green. You quickly know what you coded and what you didn't. Not helpful? Should already know? I wonder if you inherited someone else's code base if you would enjoy the green immediate feedback rather than the inference you would otherwise have to take.
When working without highlighting, I rely on the shape of the code's text and the search function of my editor to navigate as I jump around code. With syntax highlighting, I have those tools, and extra navigational cues provided by little islands of color.
I haven't noticed a difference in my scanning speed or code comprehension between the two. It may be there, but I'm not conscious of it. Consciously, I've got a slight preference for the colorization. It makes the code feel "friendlier", and I'm happier to be looking at it. The un-highlighted environments tend to be older Unix machines with other annoyances in the operating experience, so I'm sure that plays a lot into my perception.
^Ocomment.txt^X
Does vi support it, though? I know vim does.
http://stackoverflow.com/questions/19444340/how-to-specify-s...
In fact the only text editors that I know of off the top of my head that do not support syntax highlighting is notepad and pico.
Programming language keywords are different than English verbs. If you misspell keywords, your program will fail, but if you misspell a verb in an essay, nothing catastrophic happens, most of the time.
It does take me longer to read code in an uncolored ssh window than in Sublime with syntax highlighting, that's true. And I agree that semantics are more important than syntax. But I'm not sure I buy that having highlighting makes reading colored code slower than it would be otherwise. The case here didn't present evidence that it's worse. It might be a crutch, but it's also possible that the reason reading uncolored code is slower is because having syntax highlighting is actually better than not having it.
Misspelling English doesn't usually cause a complete failure, or force you to try again, that's my point. The example in the essay was a cute comparison that I think actually is worth considering, but is ultimately comparing apples to oranges.
But, no matter how fast your compiler is, the cost of finding and fixing a mis-spelling in your editor with syntax highlighting is much less expensive than finding them and fixing them with a compiler or by executing the program. Could be a few seconds per typo less expensive, but my professional experience has generally involved builds that take 1-10 minutes. I'll take the syntax highlighting crutch over waiting for my compiler to fail.
Change one character in one file that gets linked at the end of the build, the syntax check would go from 7 minutes to 3.5 on average - still too slow. You're also overlooking conditional compilation, your change might break the build on another platform - the syntax won't be checked until it hits the buildbot that flips the right flags.
> Non-trivial projects in better-designed languages...
Ah, the lets redo-everything-in-x school of thought - good luck with that.
I've not found the Alice-in-Wonderland analogy colorizing the "verbs" to be convincing.
With human language like English, we learn it and use it without the formal grammar++. A 5-year old child can speak to her mother ("I want some candy!") without conscious knowledge of "verbs" or "nouns". A formal grammar for categorization is what we layer on top of language for analysis in school. Two people can communicate and understand each other without any exposure to any grammar lessons. So yes, colorizing verbs looks superfluous and noisy.[2]
On the other hand, computer programming syntax starts with grammar. You learn that certain specific tokens are "data types" and other tokens are "literals", etc, etc. And that grammar categorization in programming languages never goes away as you're typing out new code. (Otherwise, you'd get a compiler error or unintended behavior because x="3"+"5" with quotes ("35") means something different from x=3+5 without quotes (8).) This is why so many experienced programmers find color highlighting helpful even if they've been programming that language for 10+ years. Sure we want to focus on higher cognitive purpose of "semantics" but the grammar is deeply intertwined with reconstructing what the semantics is.
A closer analogy of color highlighting in a different realm would be different colors in TCPIP traces such as "red" highlighting external ip addresses. This can be helpful for forensics of malware phoning home.
Or in financials dashboards where uptrends are "green" and downtrends are "red".
The same reasons that colors help the malware analyst or stock trader quickly parse data at a glance is also how it helps programmers.
++ (at least not consciously that a 5-year old would be self-aware of it. A theory of innate universal grammar in the brain by Chomsky isn't what I'm talking about.)
[2] except for rare examples of using annotation or coloring of verbs to help parse sentences like this: https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...
Syntax highlighting is helpful to me for the following purposes.
1. Scanning through code.
2. Making it clear what is a comment, what is a string, and what is code.
3. Catching a variety of minor syntax errors automatically. (For example failing to properly close a multi-line quote...)
4. When switching languages, reminding me when I didn't fully switch gears and wound up using the wrong keyword.
I learned to program in vi without syntax highlighting. Before I tried syntax highlighting, I thought it was silly. After I tried it, I found it made for a more comfortable environment. The difference isn't huge, but it is noticeable enough that now I always turn it on.
There are times when I log into a system to edit something with vim, and no syntax highlighting appears. It surprises me, but not a deal-breaker.
I also thought syntax highlighting was unnecessary. The first time I saw a video of using the Twilight theme for Sublime, I was stunned by what the colors brought out. At that time, my awareness was not as developed, so I couldn't even tell you I liked it because of how I experienced the code.
So I spent a lot of time finding good themes for my editors, first vim and now spacemacs. If I am going to look at code all day, I don't want my eyes to bleed. Aesthetics is the strongest argument I have for syntax highlighting, and it should not be casually dismissed without investigation.
It sounds stupid, but it matters.
Best color scheme I have found, I use it for everything. I can't even imagine opening up some of my code in notepad or vi(m) with no syntax highlighting and actually trying to do a productive amount of work. This suggestion seems absolutely ridiculous if your syntax highlighting is sane.
Really? Why is it then that we have such popularity in color schemes like Solarized[1]? Or the much older zenburn? I'll agree that there are a lot of bad color schemes out there, but that's because anyone can create a color scheme. There's no certification process to create one.
Back in the era where people "themed" their window manager (GNOME, Kwin, Windows, and even OSX had hacks for this), look at all of the really gaudy window themes that were created. Is this an argument against all theming of windows?
Is judicious use of Comic Sans an argument against fonts? Of course not.
[1] http://ethanschoonover.com/solarized
I will take that experimental data over a pile of arguments from first principles any day.
Fixed that for you.
I like syntax highlighting it, it helps me. Not some over the roof-rainbow colors, I always like minimal and dark color schemes, but I think it would definitely feel weird to code without syntax highlighting. Although I would get used to it. But if it ain't broken don't fix it.
Pick up any reference book. A dictionary, a textbook, a phone book, whatever. Leaf through it a bit. You'll find they all use text formatting to highlight things. The dictionaries I've used typically use bold for a word and its different forms, italics for parts of speech, and such. Phone books similarly use different weights and sizes for names, addresses, and phone numbers. Textbooks use bold and italics to highlight important terms and concepts and students will often mark up the books to further highlight certain things.
Code is usually not meant to be read like you would a novel; it's much more like a reference text. For me, at least, syntax highlighting is a tool that supports the ability to more easily find what I need and understand it in isolation. Maybe it would be slower for me to read a syntax-highlighted file token-by-token end-to-end than an un-highlighted one but that's not a use case I ever need.
https://en.m.wikipedia.org/wiki/Rubric
Also this claim isn't even correct - code which varies in color is not changing typeface! Really it's no different from using bold or italic in traditional prose, which nobody would complain about.
Right, because prose text never uses more than one type size, treatment, or formatting to make the content easier to read.
Why the negative comments with some folk even calling this guy wrong on an opinion piece? Sheesh, people..
The author obviously hasn't spent much time coding.
I take it that you didn't look through his list of projects. There are some impressive things listed.
"A case against traffic lights having colors. You should just pay more attention to what each dot means"
Less strain on the brain, so to speak.
Varying styles within a work can be immensely helpful, and is almost universally done. For example, headers tend to be written bigger to indicate a) that they're something different from the main text, and b) what their relationship to the main text is. Similarly, italic and bold text are used to impart additional meaning to various parts of the text. Many publications will use a different style for things like bylines and photo captions — again, because they are different things from the body text and this helps the reader pick out the parts of the page in a purely visual manner. It's even common to see parts of the body text stylized differently to indicate that they have a special function — for example, in a Q&A format, you'll often see the questions formatted differently from answers, or the identities of the speakers might be written differently from the words they said.
So not only is this philosophy about typography not necessarily applicable to code, it's not even widely accepted for ordinary written text.
I agree. However, I don't see how syntax highlighting necessarily makes reasoning code easier or harder. I don't know if the arguments are specious, but I think and feel that much of the arguments in the article are weak and unconvincing.
The author has already dismissed (without examination) the strongest argument for syntax highlighting: aesthetics. There are whole philosophies of aesthetics that makes a lot of sense, but only when we go beyond the mere results of the programming. The aesthetic argument for syntax highlighting isn't for the sake of the quality of the resulting program but rather, the quality of the experience for the programmer. That in and of itself is underestimated by a fixation on the resulting code.
There are philosophies that precisely define aesthetics, but these are generally in the non-dual philosophies, not the dualist philosophies. As soon as you have a dualist philosophy, you set up an opposition between privileging objective over subjective, or subjective over objective, and it resolves nothing. Non-dual philosophies do not privilege objective over subjective, or subjective over objective, and have a lot of useful, testable (empirical, experienceable) things to say about aesthetics.
Aesthetics bring a human perspective to the technology and reminds us that, however efficient a technology is, it shapes and is in turn shaped by our experiences as human beings.