Syntax highlighting? Programmers these days rely on Intellisense, with tooltip help explaining parameters and return values as they type.
Back in my day we were lucky to have an EDIT command in our BASIC interpreter. Back in the day of someone much older than me, patching binary files directly was the norm. How would programmers today even cope, should they ever be confronted with a hex editor or worse, a front-panel bank of toggles?
I'm admittedly a newb, but I find that a lot of my programming includes trying to think in a good way and then reading documentation to figure out how to implement it.
So far it has applied to every technology I've used. :p
That comparison doesn't make sense. You forget that the frameworks we use today to parse XML has more complexity than the entire OS had then. We are able to do so much more today, on code bases several thousand times larger, because we have these tools.
Within the last six months I used a hex editor to diagnose a problem with a PCM streaming solution and generate a "corrected" form of the output to show how my hypothesis was correct.
The bright primary colors on black shown in the post are distracting. More subtle colors make a difference. I find syntax highlighting incredibly helpful. Seeing instantly if you forgot to close a quote. Seeing comments ( as the author points out) are two examples.
I'm one of those developers that likes to have an IDE with as many helpers as possible. And before anybody accuses me of being a newb, I started out programming pascal & working on vax on a dumb terminal. And I had to walk uphill both ways to get to the computer lab. So put that in your pipe and smoke it young whippersnappers!
The important pieces are "Did I miss an end quote?" Having keywords highlighted might not be necessary (as keyword typos are rare), but knowing that the "colors look right" is a time saver, especially in HTML.
There's at least two phases of developing code. There's the solving of the problem at hand, and getting the expression of that solution towards syntactically correctness.
Colour syntax highlighting is merely a "live syntax checker" - albeit not as good as a compiler or linter (it's simpler in nature). But the value it adds is sufficient to make it a useful aid. It's the coding equivalent of Word's squiggly red line spell-checker, it draws attention to things that may be issues when the colour highlighting looks odd.
If the colours are distracting, then it is the colours that are the issue, not the concept of syntax highlighting. So subdue them enough.
Colour syntax highlighting is a visual indicator that the code looks syntactically correct. With that as a confidence indicator it's easier to dive into the logic itself, knowing that you're mostly on solid ground syntax wise.
Plus, colour provides quick visual hooks to various parts of the code. It allows skimming through the code to find the prescient part easier. Yes, it makes it easier to skip past commented out code -- those should be deleted at an appropriate point. And it's easier to delete that commented out code when it's colour coded than without.
Developers fight with their code on multiple levels. Colour-coding helps deal with one particular level of that code - syntactic correctness.
Developers know that syntactical correctness doesn't mean the problem is solved. It just means that the attempted solution to that problem is considered syntactically correct.
I think the only interesting point in the author's piece is the point that English text is more difficult to read when it's randomly coloured. When we get to an x-Generation Language levels where we can develop programs in plain English, I'd agree with the author that colour syntax highlighting doesn't add sufficient value at that point. But we are still stuck in a hybrid computer-friendly constrained language constructs, and with those constrains, colour syntax highlighting assists developers to confirm the code is syntactically valid.
You said “I think the only interesting point in the author's piece is the point that English text is more difficult to read when it's randomly coloured.” Åkesson didn't talk about random colors. His sample text isn't randomly colored. It's colored by part-of-speech. Nouns are red, verbs are green, etc.
I find the yellow and green parts of his sample text particularly difficult to make out, because of those color choices, not because of the changing of colors from word to word. If Åkesson wants to claim that “it will inevitably decrease the legibility of the text”, he needs to cite a study demonstrating this. As far as I know, he's just speculating.
We have a historical reason, at least, for writing prose in just one color: it is much easier to write or mass-print in one color. But now we live in an age of computers, and we could perhaps have the computer syntax-color our prose when we read (and write) it on screen and print it to a color printer. If a reader had time to get used to reading syntax-colored prose (and the color scheme were chosen well), would the reader be able to read faster or understand the material better? This question has to be answered by testing, not speculation.
"If a reader had time to get used to reading syntax-colored prose..."
Ha, that's exactly what I thought when I saw that example, too.
Wouldn't written English be much easier to learn (for both children and for ESL learners) if we always wrote the different parts of speech in different pleasant/subtle colors?*
It would certainly make skimming text much easier for advanced readers - much as syntax highlighting makes skimming source code much easier for professional developers.
*(Or perhaps slightly different typefaces to get around colorblindness issues.)
I don't think it has to be an either/or proposition. I read some things and skim others. You'll be happy to know I read your entire comment word-for-word. :-)
Sure, I mean't in the sense that "British researchers say we (the internet generation) are getting worse at reading books (but we're very good at finding the useful information in a crowded website).
I don't think much of the case made, but this was interesting:
"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."
In fact, research[0] shows that we understand and remember text better if it's harder-to-read than if it's easy.
Natural languages have syntax highlighting; note the capitalization of proper nouns in English, or better yet all nouns in German, along with capital letters to start sentences. There are various typographical standards, all of which provide syntax highlighting, and it's arguable punctuation serves a related purpose (note the pairing of certain marks in Spanish).
after all you can still read this without it but it takes more effort i think the author may have glossed over the aspects in language because they have faded to background noise if your syntax coloring is a distraction change it if it works dont
Syntax highlighting helps me read code very much.
I notice this every time I end up in an SSH session looking at code in some version of nano without it enabled or when reading code on a webpage that is not highlighted.
Our brains are designed (or evolved) to look for patterns in things, colours help this.
Most of the time when I am in code I am not interested in reading the whole thing anyway, I just want to make a quick change to something like, for example the contents of a particular string.
In that example having the string literal inside the quotation marks light up in a different colour makes it much quicker to distinguish it from the rest of the code, the same the comments.
It also makes it much easier to distinguish where function definitions start if the definition is in bold.
Coupled with the fact that it makes it easier to spot spelling errors in keywords since they will not light up the expected colour.
I think I can also spot common patterns of code (like say foreach statements) more quickly because of the the pattern is reflected by the pattern of colours on a line.
The only problem I see with relying on syntax highlighting is that it lets you manage superficial complexity and clerical details, but doesn’t address fundamental complexity. What you can get in extreme cases is heinous code that’s only tolerable to read with highlighting.
In the vast majority of cases, though, it’s helpful to ensure basic superficial correctness so that you can focus on details that actually matter. And people who program for any nontrivial amount of time develop very good attention to detail anyway.
His example of how it is hard to read ordinary English with syntax highlighting is not very persuasive, because of the fundamental differences between written English and most programming languages.
English is a native human language. Humans are born with a capacity to efficiently learn one or more native languages. From very early in your life you start learning your spoken native language. An adult has from 20 to 100 years of exposure to the language, and all that time their brain has been improving its skill based on what they hear when others speak the language.
Written English is essentially a representation of spoken English. When you read written English, you read the words, and your brain processes them, analyzing their relations and identifying their roles.
For ordinary written English, then, I'd expect that reading would be most efficient when presented in a way that makes it easiest for us to recognize the individual words accurately and quickly. That gets them "inside" as fast as possible, in a form that lets our brains treat them similarly to heard words.
If we color the written text, I'd expect the coloring to slow down the raw rate of recognizing words, because of the distraction of the colors. The question then is whether having that extra tagging does anything to speed things up so as to overcome the slowdown in the raw rate.
I'd expect the answer to be "no", because at that stage of the process of reading, I don't think our brains care about parts of speech. That comes after the word is recognized and the stream of words is being processed like a stream of speech.
Note the above is all for "ordinary" English. I have found that when the English is considerably more complex than what we normally encounter, highlighting parts of it DOES make reading go faster.
For instance, consider law. One will sometimes find in statutes single sentences that take half a page or more, and have subclauses and intricate and complicated relations among the various parts of the sentence. When I was in law school, I had 5 or 6 highlighting markers of different colors, and I would use color to highlight the structure of the law. For instance, if a long sentence was structurally 4 subclauses connected by "or", I might highlight the "or"s between the clauses all in the same color.
In appellate court opinions, I might dedicate one color to highlight mentions of plaintiff in the original case, another to the defendant. I might use another to highlight cites that the court is agreeing with, and another for cites that the court is distinguishing this case from.
The key here is that the written English in these cases (no pun intended) was complicated enough that if it was spoken it would be hard to understand. You generally can't just read it through once and get it. To build up your understanding of it, you have to grasp the structure, and use that to guide you to grasping the meaning of the parts and how they relate to each other. You read it non-linearly, and the highlighting helps.
So now let's turn to programming languages. My contention is that programming languages are generally more like statutes and court opinions than they are like ordinary written English. Understanding a complex program is an iterative process that involves grasping the overall structure, then understanding small sections, which then improves your understanding of the big picture, which clears up some things about the smaller sections, and so on. You don't read linearly. You jump, just like when reading law. The syntax highlighting provides places to jump to.
24 comments
[ 4.1 ms ] story [ 63.5 ms ] threadBack in my day we were lucky to have an EDIT command in our BASIC interpreter. Back in the day of someone much older than me, patching binary files directly was the norm. How would programmers today even cope, should they ever be confronted with a hex editor or worse, a front-panel bank of toggles?
So far it has applied to every technology I've used. :p
So I think today's programmers will do just fine.
I'm one of those developers that likes to have an IDE with as many helpers as possible. And before anybody accuses me of being a newb, I started out programming pascal & working on vax on a dumb terminal. And I had to walk uphill both ways to get to the computer lab. So put that in your pipe and smoke it young whippersnappers!
Colour syntax highlighting is merely a "live syntax checker" - albeit not as good as a compiler or linter (it's simpler in nature). But the value it adds is sufficient to make it a useful aid. It's the coding equivalent of Word's squiggly red line spell-checker, it draws attention to things that may be issues when the colour highlighting looks odd.
If the colours are distracting, then it is the colours that are the issue, not the concept of syntax highlighting. So subdue them enough.
Colour syntax highlighting is a visual indicator that the code looks syntactically correct. With that as a confidence indicator it's easier to dive into the logic itself, knowing that you're mostly on solid ground syntax wise.
Plus, colour provides quick visual hooks to various parts of the code. It allows skimming through the code to find the prescient part easier. Yes, it makes it easier to skip past commented out code -- those should be deleted at an appropriate point. And it's easier to delete that commented out code when it's colour coded than without.
Developers fight with their code on multiple levels. Colour-coding helps deal with one particular level of that code - syntactic correctness.
Developers know that syntactical correctness doesn't mean the problem is solved. It just means that the attempted solution to that problem is considered syntactically correct.
I think the only interesting point in the author's piece is the point that English text is more difficult to read when it's randomly coloured. When we get to an x-Generation Language levels where we can develop programs in plain English, I'd agree with the author that colour syntax highlighting doesn't add sufficient value at that point. But we are still stuck in a hybrid computer-friendly constrained language constructs, and with those constrains, colour syntax highlighting assists developers to confirm the code is syntactically valid.
I find the yellow and green parts of his sample text particularly difficult to make out, because of those color choices, not because of the changing of colors from word to word. If Åkesson wants to claim that “it will inevitably decrease the legibility of the text”, he needs to cite a study demonstrating this. As far as I know, he's just speculating.
We have a historical reason, at least, for writing prose in just one color: it is much easier to write or mass-print in one color. But now we live in an age of computers, and we could perhaps have the computer syntax-color our prose when we read (and write) it on screen and print it to a color printer. If a reader had time to get used to reading syntax-colored prose (and the color scheme were chosen well), would the reader be able to read faster or understand the material better? This question has to be answered by testing, not speculation.
Ha, that's exactly what I thought when I saw that example, too.
Wouldn't written English be much easier to learn (for both children and for ESL learners) if we always wrote the different parts of speech in different pleasant/subtle colors?*
It would certainly make skimming text much easier for advanced readers - much as syntax highlighting makes skimming source code much easier for professional developers.
*(Or perhaps slightly different typefaces to get around colorblindness issues.)
"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."
In fact, research[0] shows that we understand and remember text better if it's harder-to-read than if it's easy.
[0] http://web.princeton.edu/sites/opplab/papers/diemand-yauman_...
after all you can still read this without it but it takes more effort i think the author may have glossed over the aspects in language because they have faded to background noise if your syntax coloring is a distraction change it if it works dont
(That was surprisingly hard.)
Syntax highlighting helps me read code very much. I notice this every time I end up in an SSH session looking at code in some version of nano without it enabled or when reading code on a webpage that is not highlighted.
Our brains are designed (or evolved) to look for patterns in things, colours help this.
Most of the time when I am in code I am not interested in reading the whole thing anyway, I just want to make a quick change to something like, for example the contents of a particular string.
In that example having the string literal inside the quotation marks light up in a different colour makes it much quicker to distinguish it from the rest of the code, the same the comments.
It also makes it much easier to distinguish where function definitions start if the definition is in bold.
Coupled with the fact that it makes it easier to spot spelling errors in keywords since they will not light up the expected colour.
I think I can also spot common patterns of code (like say foreach statements) more quickly because of the the pattern is reflected by the pattern of colours on a line.
In the vast majority of cases, though, it’s helpful to ensure basic superficial correctness so that you can focus on details that actually matter. And people who program for any nontrivial amount of time develop very good attention to detail anyway.
English is a native human language. Humans are born with a capacity to efficiently learn one or more native languages. From very early in your life you start learning your spoken native language. An adult has from 20 to 100 years of exposure to the language, and all that time their brain has been improving its skill based on what they hear when others speak the language.
Written English is essentially a representation of spoken English. When you read written English, you read the words, and your brain processes them, analyzing their relations and identifying their roles.
For ordinary written English, then, I'd expect that reading would be most efficient when presented in a way that makes it easiest for us to recognize the individual words accurately and quickly. That gets them "inside" as fast as possible, in a form that lets our brains treat them similarly to heard words.
If we color the written text, I'd expect the coloring to slow down the raw rate of recognizing words, because of the distraction of the colors. The question then is whether having that extra tagging does anything to speed things up so as to overcome the slowdown in the raw rate.
I'd expect the answer to be "no", because at that stage of the process of reading, I don't think our brains care about parts of speech. That comes after the word is recognized and the stream of words is being processed like a stream of speech.
Note the above is all for "ordinary" English. I have found that when the English is considerably more complex than what we normally encounter, highlighting parts of it DOES make reading go faster.
For instance, consider law. One will sometimes find in statutes single sentences that take half a page or more, and have subclauses and intricate and complicated relations among the various parts of the sentence. When I was in law school, I had 5 or 6 highlighting markers of different colors, and I would use color to highlight the structure of the law. For instance, if a long sentence was structurally 4 subclauses connected by "or", I might highlight the "or"s between the clauses all in the same color.
In appellate court opinions, I might dedicate one color to highlight mentions of plaintiff in the original case, another to the defendant. I might use another to highlight cites that the court is agreeing with, and another for cites that the court is distinguishing this case from.
The key here is that the written English in these cases (no pun intended) was complicated enough that if it was spoken it would be hard to understand. You generally can't just read it through once and get it. To build up your understanding of it, you have to grasp the structure, and use that to guide you to grasping the meaning of the parts and how they relate to each other. You read it non-linearly, and the highlighting helps.
So now let's turn to programming languages. My contention is that programming languages are generally more like statutes and court opinions than they are like ordinary written English. Understanding a complex program is an iterative process that involves grasping the overall structure, then understanding small sections, which then improves your understanding of the big picture, which clears up some things about the smaller sections, and so on. You don't read linearly. You jump, just like when reading law. The syntax highlighting provides places to jump to.