Why syntax highlighting is bad

Good writing! Thank you! If only more coders would care more about their code. Sometimes simplifying your environment is all you need. Just to quote Brian Kernighan "The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

I've come across your article because I was pondering on the same ideas and I just did a google search. Nice article. I have an idea. This way we are distracted towards the error, to fix it, else we focus in the code at the semantic level. What do you think about that? Cheers, Sam. Well, that was a lot of talking. After reading everyone's opinions, I've came out with my own. I utilized other thoughts, and here is the result: If you would apply your logic to everything syntax highlighting is like training wheels for the bicycle: when you get rid of them, you will get pulled out of the 'comfort zone' and would be forced to relearn again a.

Because electricity is basically the same thing: without it, some people wouldn't live that long and therefore it should not be used at all. For me, it is not the way to go. At least because in some cases it would use up more time.

But the main reason, which applies to almost everything invented, that explains why insert any invention here is invented at all, is time. As the saying goes, time is money. And sometimes, you can make more money by using less time. It's like gambling. In conclusion, use syntax highlighting for your own risk, by understanding the fact, there will be a day when it suddenly disappears For example, say a string literal is being passed in a function call.

In essence, there are two bits of information for a programmer to be aware of: 1. A string literal is being passed 2. It's right that I can saccade past the contents of the string if right now I'm not interested in that argument, and need to examine another argument to the function more closely. It is wrong to be forced every time to track my eyes across carefully, and find the closing quote, before I can look at the next argument to the function.

These little inefficiencies add up. The analogy with a novel is false. A novel must be read in a linear fashion. For most modern code paradigms it's not even clear what linear would mean a source file, a stack trace, an inheritance hierarchy?

Furthermore the English language does not have the same kind of formal syntactic structures as code: function calls, literals, operators, macros etc are not merely different kinds of words. It also occurs to me that you've had a bit of a free pass with the "seeing the woods for the trees" comment. It's the kind of statement that seems intuitively right, and most programmers at first glance would consider it to be important. But on reflection, I don't believe it is important, or even correct.

For any sufficiently complex program, abstraction is incredibly important. When I'm writing a class I should be concerned with just what that particular class does. And in terms of calling other classes, it should be safe to forget how they internally work. If I can't do this then this implies poor design and a creaky system. And needless to say, there should not be global variables, or shared states. I should be able to focus on a single method at a time because everything is so neatly encapsulated.

So being able to work at the "trees" level is actually an ideal. Now I'm sure you'll say that what you mean is the big picture: an awareness of what the whole shebang is doing, and is for.

But again, for sufficiently complex programs that level is far above the level of actually looking at source code. Understanding the big picture, and your preferences for displaying code, are very far removed. The language Esperanto is easy for beginners to understand partly because of its "syntax highlighting": all nouns, verbs, adjectives and adverbs have their respective word-endings that make them consistent.

One can read a text and pick out all the nouns by form alone. So no, it's not crazy for natural languages to do this. My say: it's always better to have an option than not to have one. Interesting point of view. I would generally say that syntax highlighting is not evil : I agree that some schemes don't actually work or make the programming eye lazy or cluttered! The broken learning curve example with the wheel I believe is a loose generalisation. Software quality is at most cases achieved by constant redesign and code review.

Yet, I agree with you totally that syntax highlighting should be investigated further because it could actually play even a greater role in program creation if addressed correctly Congrats for the article and thanks for your constructive critisism Two comments - firstly I have seen English written coloured, in a class with dyslexics the words would often be written coloured and referred to as "green words" and "blue words".

That was many years ago now I'm nearly 40 and I reckon the people concerned still think of the words by colour instead of their actual function in English. Secondly - a very real use for syntax highlighting - being a dope and forgetting to close quotes in strings. What is that expressed in code? Your compiler ought to tell you about this. If I was highlighting music with colours, perhaps I would consider colouring repeat signs, tempo and phrasing markings, accents and section breaks.

Colouring each note differently would be like colouring an int differently than a string. We don't do that in most code highlighting schemes. In the past in my music studies I would colour sections of music with the same theme in the same colour in order to aid memory, while that is different than the highlighting of code, there is indeed a valid use for highlighting in music.

Also sometimes I will highlight the tonic of a scale to show it is special for my student's learning. Wow, I can't believe a programmer actually wrote this article. Research has shown many times that well chosen secondary notation helps with program comprehension. In some cases like indentation the benefits are huge. Exactly my thoughts since the day I stumbled upon the first editor with syntax highlighting -- the first thing I did was turn it off, and I do it ever since.

When I see a screen of code with a distracting mix of awful colors, I can't understand a single line of it.

And I agree on the exceptions too, mostly. My own IDE has exactly two cases for syntax highlighting: Comments and strings. Apart from that, too bad that "Swedish law applies" to my comment.

I may not even touch women in that case ;-. I have written a terminal emulator for my own use and one of its features is that it ignores requests to change colours. So my terminal shows nice, consistent text no matter what the programs I run think the colours should be. It does, however, support bold and underlined text as I find those are less often abused and are less distracting.

Another point that came to mind about syntax highlighting in particular is that I use different programming languages and I look at diffs and grep output, for example, and other variants of texts. It would be silly to try and find consistent colouring rules for all the ways I have of interpreting text. Sorry, but I disagree. It's a real productivity booster personal preference: Emacs. WRT training wheels, I might just as well put up an argument against use of power tools.

Rather than comparing syntax-highlighted code to syntax-highlighted English prose, it would make more sense to compare it to a syntax-highlighted set of step-by-step instructions. What about semantic highlighting? You must be an academic and not a practical programmer. Typography doesn't mean shit in this case. Typography wasn't meant for this level of abstraction.

Using your logic, one could also argue that mathematics should only be written in certain font-types. Otherwise it just wouldnt be that good, or something. Or that the matematichian couldn't understand his work, because the font is different.

For example Coda2 on MACs doen't highlight the end tag or bracket , if you have focus on the start tag or bracket. You'll be wasting your time together with the clients money. Simple as that. Some people can build a program in 20 hours, and other can do it in 1 hour. You're the 20 hour guy. Nobody is gonna pay for that shit It's hobby-level, not pro. In the real world, you're not gonna get to play an academic, and use hours upon hours on a project, writing reports and analyze every bit.

Not gonna happen in the private market. Just not practical enough for a private business, where the real work gets done. Your conclusion is wrong. Syntax highlighting does the exact same thing you says it doesn't do.

It makes you focus on the important stuff Getting payed by a happy customer. No customer is happy paying some freak to spend 5 times the hours, than others. This entire article is bullshit. Stop going to school and do some goddamn work instead! Nobody is gonna pay you for this shit. Using the argument that "syntax highlighting confuses you", makes me absolutely certain,that your brain works one or several levels below other programmers, who don't get confused by colors on the screen.

Get a job, and stop waisting all your evenings perfecting syntax. I work as a programmer, and what I read in this article, defies absolutely everything i know about being fast.

It's like argumenting against autocomplete functionality, because it might encourage youth not to learn language or grammar. You should be a politician and not a programmer.

I used to work as a carpenter Same thing there. Customers don't care about how well you know how carve wood, or if you can do sculptures They care about what you build, how fast, and what it will cost them. Your arguments violate all of this. You sound you cost a lot, just by thinking about obvious stuff.

It's like arguing that all text should be handwritten, or we wouldn't understand how characters work This article gets my piss boyiling, because it's just so wrong, in every practical level. I didn't find such studies, but kudos for raising the topic! It is true that Linus does not back up his claims by experiments, like a speed reading test. But, amusingly, his most vocal critics here seem unaware that they too must back up their claims with figures instead of gut feelings.

I think this topic deserves a methodical study. I'd surely love to see figures how much syntax highlighting helps or distracts depending on the circumstances. Here is a key part of the conclusion page 51 : "A suprising finding was that the control scheme, black text on white background, resulted in the same overall search performance as the other coloring schemes.

The participants' overall comments on color usage were positive and they reported of perceived performance improvement. However, the results of the experiment do not support his intuition. This is basically a nice thought technology for some people to try rather than rejecting it out of hand. I work in 'big iron' mainframes where some of the editing tools lack syntax highlighting and others have syntax highlighting.

Most new comers and experienced people report finding the lack of syntax highlighting slows down their coding and leads to more errors that are harder to find. A minority maybe the geniuses? Given my experience it makes sense for you to follow Linus' advice and try out the options and see what group you are in.

From years of personal experience I know I am in the 'syntax highlighting helps me' camp. I FTP code out of environments without syntax highlighting to put it into editors with highlighting and often immediately see bugs I have spent ages searching for or find design flaws that leap off the screen with some help these are declarative and or interpreted tools with no compiler to help me.

But that doesn't mean the same is true for Linus or for you. Give it a try and find out. Perhaps I am in the dumbo camp and Linus and you are in the genius group. It is cheap to find out. If I have a bad knee I will use crutches without shame, it would be better to not have to use them but if they get me to my goal faster or with less pain then I am not going to deny myself the help on a matter of principle.

But if crutches are getting in your way more than they help then you would be a fool to keep using them. The argument that people should only comment if they have solid statistical data is simply missing the point of what stats do and don't tell you.

Group stats tell you nothing about any individual in a group. Even if Therefore you should use option B if it makes sense to do so even though it would be a bad choice statistically.

Thanks for your post. What is true is that you have to view the same thing in different ways I will start different modes of operation: If I'm in a hurry: syntax highlighting If I have time, I will relax myself: no syntax highlighting.

I tend to prefer syntax highlighting when typing mostly to avoid typing mistakes the color change gives me a sort of "satisfaction" that I typed at least something properly. Maybe the problem with syntax highlighting is when it gets too much.

Like do we really Eclipse to put something in italics if it is a static member? I hate that default setting and always turn it off. If there is just a few simple syntax highlighting elements then its fine, but if the number of distinct color categories gets to be more than a few then it quickly becomes of decreasing utility to me. I think syntax highlighting for prose may not be such a bad idea after all. If you trained yourself for the colors, it might become much easier to skim through text.

Could be useful if you don't need to understand the content too deeply. It is what describes semantics to both people and machines. Different syntax highlighting is actually subtly different concrete syntax, just as different stylistic convention is subtly different concrete syntax.

So it can and often does imply differences in semantics. That the highlighting goes away and is rebuilt differently between different editors and IDEs is the core of the problem. If the typography was precisely communicated in the source code of the program and everyone would see the same thing when they looked at it would not be a problem.

But this isn't the case, so it is a problem. It compounds subjectivity in reading source code. Not only do people simply think different things when they read the code, it is actually presented to them differently; hiding things that are obvious to others, and drawing attention to things that are not.

Rather than syntax highlighting being bad, the fragmentation of source code presentation is bad. Two very different approaches to fixing this are that of something like smalltalk, where the programming environment is 'built in', and everyone who works on the code uses that same interface; or that of something like golang that is packaged with a tool gofmt that transforms any valid go source file into one with a canonical layout. Golang also establishes a convention of applying this transformation to all golang source code before sharing it with others.

Where it is not a part of the established tooling for the language, it either amounts to inconsistency or an additional dependency. Neither of which is a good thing in the general case. Removing inconsistency makes the human interpretation of your code more coherent, and removing dependencies gives your software an additional dimension of freedom.

It makes your code more portable between readers and allows you to use tools that might not provide the required dependency syntax highlighting. Computer code isn't meant to be read like a text file. Syntax highlighting makes that structure transparent, until you need to read or edit it. For control structures, once they are in place and correct I don't need to look at them again and syntax highlighting, again, makes that transparent. Try Solarized or some other syntax highlighting scheme that doesn't have sharp color differences.

While code is a text file, it is not prose, but really a document that relies on structure which doesn't have to be parsed along with the contents it contains. I can only assume the writer of this post has never worked with code that was written a long time ago, by many people who were adding functionality to the program without cleaning up after themselves or cleaning up other peoples mess.

When you start working with code that is poorly written, you can encounter situations where a global variable, a function argument and a local variable within a section of the code are all named the same. Having all these variables look the same on the screen adds to the general confusion of reading the code, wouldn't it be nice to have better syntax highlighting for these cases?

When you encounter a situation like the one I am describing, you can be the judge. Check any structured book - e. Highlighted text is always easier to read as long as you deal with some structured data - it is no wonder that such basic command line utilities like "ls" have it too.

Highlighting is made to make LOOKUPS easier as opposed to reading through as you'd do with prose book and lookups is exactly the thing you'd be doing most often while working with code.

Interesting discussion. I actually researched this at UNI back in and found a statistically significant improvement regarding the speed at which undergrads spotted simple bugs when colour coding was used to highlight basic code structure e.

What If Then etc. This was compared with black and white and with and without indentation. That said I think there is an a lot more study needed to work out the ideal balance and most of the above comments are valid.

Colour can be distracting check out the Stroop effect. Oh my goodness, such elitist. Which what syntax highlighting does, ease debugging on the fly. Otherwise, do you want to debug for the rest of your life? Because that is how you debug for the rest of your life.

And making changes in code that one doesn't fully understand is bad, dangerous behaviour. The syntax highlighting distracts us from seeing the forest by making it easier to see the trees. Maybe we got used to.

I open a code file with plain notepad. My brain has a hard time. But there is a difference of course. The colors are not as glaring as in the screenshot. But there should be a time where I never had such luxury when coding.

I just don't remember it. Or maybe the fonts on the notepad and the white background are not helping. Maybe I should try some DOS compiler with blue background and proper easily readable fonts.

It's like I got used and can't look code without color intentation. Light colors, not glaring. I could say the same about autocomplete. I got used. People tell me the same, how the hell can I code without double screens.

I still have a single screen at my home. Maybe I'll get used to two screens some time and then it's hard to get back. I am wondering actually how this works in code. So, the idea is, would it be possible that looking at code that is not as easy to read, would have different effects in problem solving?

Not tabs would be a problem. But no color highlighting could be okayish, because once upon a time we didn't need it and code wasn't that bad. Just an idea, because my instinct says it helps, but what if in specific cases, pushing a bit the brain to understand text will lead to better understanding of code or problem solving? I cannot agree. Colores can be misleading or helpful.

In your paragraph of quoting, you make it misleading, although you marked all words of same type with the same color, because it's not structured like we do in programming and so it cannot stand. Even you argue it's not part of your article, the image you use tends to mislead readers to agree with your point.

So it's not proper. And, if we think colors can be distracting, can indentations be? And wrong formatting? My point is, all these visual elements help us to understand the semantic part, and are useful for many. If they mislead you, they are not properly used, doesn't mean it is nothing worthy. And, if you skim and ignore important informations, maybe you skim wrongly.

You cannot blame the colors. One example of mine: when I enter a new Company, I need to adapt myself into new projects, and syntax coloring helps me to identify each element and each type, to get to know the structure of every function, method, class, etc. If I have glipsed several lines of Calendar. At last we seperate code in different lines, we use indentations, we use spaces to make it more readable, not only syntax coloring.

Reading code is a combination of format, not only marking them with color. So, I insist that if we find that the format or syntax coloring is misleading, it may not because we are not paying attention, or they distracted us, but we use them in a wrong way, so we change them to fit our purposes. With some languages and their naming conventions syntax colouring or highlighting is an absolute must without which the language is totally disfunct.

For example when using the C family of languages in combination with their prevailing all-lowercase with underscore naming convention, syntax highlighting is an absolute must have to stay sane when reading the source.

It was designed for human readers. By contrast, the C family syntax cannot stand on its own, it requires syntax highlighting to separate individual identifiers. This syntax was not designed for humans, it was designed for machine reading efficiency only. When a syntax that was designed for machine reading is being abused as a tool for human writers and readers, then it must be augmented so that it becomes legible to humans.

We also do so with other syntactic entities that were not designed for human readers, for example long columns of digits are often separated by some separator symbol for human consumption even though they do not add any meaning: ff:abf0:c0 It would be ridiculous to suggest that the separators shouldn't be used to make the data more human readable simply because one has to learn to read huge numbers of columns without separators.

What for? To show off? In your Alice example, you have used the wrong syntax colour for the word White. Well said, my friend. When I started programming, color highlighting would have been impossible because all monitors were either white, green, or amber.

But even with modern IDE's, I find coloring to be distracting. They are lost amid a WASH of colors. To add to your "exceptions", here are the only other areas that I find color highlighting helpful. Unterminated strings. That sort of thing. Pretty much the same observation you made about landing in a patch of commented out code. Kirby Wallace ;-. Currently sitting halfway in abject disbelief. If you can dig through those without admitting highlighting plays a critical role in legibility, you're kidding yourself; but you're not kidding every reader shaking their head over this tripe.

Sounds lot like comparing a "Automobile" to an "Airplane". Both are machines yeah, no doubt, providing similar solutions, 'transport'. Remove all the "extra" "detectors" and "sensors" from the airplane because that's not the pilot's problem since the factories manufacturing the airplanes are already suppose to handle that, 'equipment error'. The pilot's job is to only keep his eyes wide open check left and right probably and fly it that's what you're suggesting.

Me, personally, if I were a pilot, I'll never fly that plane never ever. I apologize: English is not my native language, so this comment might be riddled with horrible and mindboggling mistakes. But I'll try my best to keep their numbers as low as it's possible. Thank you for your article. It spawned few discussion threads in comments that I found wastly interesting.

Those made me richer - in new ideas, at least which is not a small thing, I recon. As I see this theme now: highlighting is enhancement, which when used inappropriately, can dull your professional skills with certain languages or systems.

But enhancement nonetheless. So, as every pseudo-intelligence helper like shell filter, or visual element in GUI Those would be horribly unreadable if read without highlighting. I mean, at all. For me at least. Long tags with lots of properties like classes or data Or it would be too bothersome. In more C-like languages, I like a more minimalist take on highlighting: 3 highlighting colors of '1.

In some cases language constructs would be interesting to take into 4th group but that varies from language to language, from program to program. I really like bright-red highlighting of ' TODO' in code. It is not required, but it brings a nice touch to my workflow my memory is that of a goldfish. When writing server-side code for pages - processing HTML-forms input, organizing sanitation of input and database queries, I would be thankful to have visible representation of invisible characters.

Actually, I would like to see those in any place of a code. I need a working Unix-like workstation - MS Windows weird water pipes are not good enough for my needs I assume that articles that you outlined in your article could be interesting for me, in a case if I would be developing C programs.

Which as of now, I am not. So, perhaps it depends on programming language? I view programming from the perspective of a language. I know that this kind of view point is absurd. I find that looking at highlighted text is a distraction for me.

I also believe that allowing colored syntax to help me pick out variable and functions and comments just seems too much assistance. However, highlighting text does have its benefits. For example: highlighting a line of text which you are trying to remember which concerning a concept or point of view. Underlining or highlighting is great for picking out main points from paragraphs.

But it's not used to highlight the differences between a noun or a pronoun, or a verb from a adverb. These things need to be taught without the use of highlights. I see some more benefits, mostly when there are naming collisions.

Syntax highlighting - warns when you accidentally have a naming collision with one of the countless windows macros. Things that aren't absolutely obvious immediately thats where syntax highlighting is useful. I know I'm late to the party, but I liked the article. It's a valuable perspective and critique, and I likewise understand the passion sparked by the argument instead.

Speaking as a non-neurotypical programmer, however, I feel the issue is more nuanced: I'm not sure the proposition is as binary as the article seems to paint it. This causes developers to fixate on form rather than function. These points are fair, but I feel they are predicated on the notion that this is all that syntax highlighting can offer, particularly for programmers whose brain architecture and thus cognition may differ from that of the norm.

I do not consider myself stupid although that may be the Dunning-Kruger effect talking , but I do quite often feel stupid when faced with the common tools of the profession. To me, the benefits of syntax highlighting go well beyond simply allowing me to tell the difference between an object and a type.

I shall forbear from quoting Dijkstra's observations on phrenology, and instead simply observe that given the choice between expending significant cognitive effort on following code execution and instead using that energy to be more productive, I much prefer the second option.

So what does syntax highlighting give me? In addition, my mind is visually oriented: it uses shapes and colors to attach meaning. The way my brain partitions a program is thus a natural fit for a discreet application of color. It makes the code structure itself distinct to me, which is a very good help when getting my bearings, and prevents my brain from spinning out of control and overfocusing on the wrong things.

That is a massive boon for me, because I can still easily see where things are, I'm just not forced to pay attention to them, allowing my brain to assign them a smaller portion of my attention. I would question that. To the contrary, I believe both are necessary in order to advance: it's part of what makes high-level abstractions leakiness and all such a powerful concept. When I look for bugs, a total in-depth understanding of all the code that passes under my eye would be detrimental Instead, I skim, and while syntax highlighting may encourage skimming, I submit that is so for another reason: because it makes skimming viable and a useful tool for quickly evaluating the gist of a given piece of code.

For someone such as I, who read code iteratively, it is a godsend. I have no idea what I would have done if I hadn't had that feature, but I suspect refactoring would simply not have happened. It does not, however, invalidate the concept itself.

All it proves is that syntax highlighting falls short of perfection. So I think there's value in syntax highlighting. It certainly helps me. However, there's a good case to be made against syntax highlighting as it is. On reflection, I've come to realize that the issue rather resembles the criticism levied against Hungarian notation, and that seems to indicate that the problem isn't so much that syntax can be highlighted but that it's often highlighted in the wrong manner and for the wrong reasons.

We generally don't garish colors for all the types and objects and keywords. As an old-skool programmer, learned to type on a hollerith punchcard machine, having just started in an environment where every syntax colouriser under the sun has been applied I find it hugely distracting.

But that's my personal preference, the guy I took over clearly loves his coloured object. I just find some of the colours are really unreadable. I suspect that there's a median ground that most people would accept is helpful and the uncoloured or completely garish schemes are probably less acceptable to most.

Why is this any different? 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.. 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 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.

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. 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.

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. 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. Misspelling the keyword happens relatively early in the compiler pipeline during parsing. If your build hasn't changed very significantly i.

Anything else is a failure in the design of the compiler or build system. Non-trivial projects in better-designed languages can easily take a tiny fraction of that time. 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. 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.

Ah, the lets redo-everything-in-x school of thought - good luck with that. 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 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. 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.

What happens when your compile step takes a full minute to complete? Sure it's only a minute lost, but it also breaks your flow. Not all languages are compiled.

I understand the spirit, but it is wrong. Syntax highlighting is helpful to me for the following purposes. Scanning through code. Making it clear what is a comment, what is a string, and what is code. Catching a variety of minor syntax errors automatically. For example failing to properly close a multi-line quote 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 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 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. It sounds stupid, but it matters. 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. So not only is this philosophy about typography not necessarily applicable to code, it's not even widely accepted for ordinary written text.

Apparently I'm supposed to believe "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. Right, because prose text never uses more than one type size, treatment, or formatting to make the content easier to read.

Not this again. You should just pay more attention to what each dot means". This is the best pithy response to this argument I've seen, thanks. Can't wait to bust it out next time. I think that comparison between text and code is wrong! I as an admirer of Lisp can only evaluate such a choice.

Develop your programming language. Backlight mandatory, it helps to think. As soon as the language has a set of syntax rules, the first thing that made, -- the backlight. Now, they rule it together with the revision of the syntax. Backlit make less mistakes, especially stupid. Also I can assume that it is individual, and there are people who prevent the backlight. For myself, I made the difficult illumination in the style of the old Borland IDE, helps me to think it is.