2 ms·

:syntax off

8 points by stock_toaster 14y ago

saurik 14y ago
Many of the same arguments would apply equally well to removing whitespace and punctuation from natural language, something that many people today in some (even large) cultures--and certainly those living a thousand years ago who spoke many of the dominant languages at the time--would describe using "don't want". Color is just another axis along which information can be communicated to you, one similar to using bold fonts to indicate "this is a keyword" (which many textbooks do) or italics to mean "this is important" (which many articles do) or different fonts to indicate "this was block quoted from a typed document" (which many books do). It would actually be kind of interesting to set off proper nouns in a special color (and in fact some languages do this, both human and machine, using capitalized first letters), or to highlight pronouns in colors that matched their references (to make random access scanning in fiction books faster and easier). If the colors aren't working for you, you might want to figure out how color could be better applied to your problem, but throwing it out entirely is just having fun accepting and working around the challenge of a handicap: next you might try removing language features such as "classes" or even "functions/procedures" from your experience, as "real programmers" do not need these distractions and without them you will probably spend more time paying close attention to your control flow. (In fact, while that sounds silly, spending a few months coding in nothing but assembly language is actually quite mind-opening.) (Also, FWIW, Rob Pike--the inspiration for this article--actually makes arguments similar to this for why Go is a great language: that by having fewer features, people will make less mistakes... very similar to the reasons why people designed Java as limiting as it is, and why thousands of developers insist on using C instead of C++ or assembly instead of C.) (<- All of this typed without the usage of paragraph breaks, as I'm certain that without them people just pay more attention to the argument structure ;P.)
- stock_toaster 14y ago
  I think the difference with your example of bold and italic text is different because they are occasional, so they are more signal than noise. They stand out as different because they are. I see quite a few color themes where everything seems to be a different color -- the signal of color almost gets lost in the noise. So I think I disagree with the author of the linked article to the extent he takes it. However, the article has made me wonder if a much simpler color scheme that highlighted strings and syntax errors only, would be a bit more straightforward and more signal than noise.
ollysb 14y ago
I'm not sure I buy this. Reading a book for example, you always read a book linearly. When I'm reading code I'm looking for different details at different times, I'm doing a lot of scanning. Sometimes it's functions, other times variables, strings etc. but being able to scan only items in a particular colour really speeds up my search. Syntax highlighting really helps with this. I'm also not sure about the idea of trying to hold more code in your head. Over the last few years I've changed my practices so that I don't have to hold much information in my head. For me this is one of the key benefits of TDD for example. At this point I find context switching easy to do because I've externalised the majority of my process to tools and practices. If anything, good syntax highlighting makes code a real pleasure to read. Coming from java/eclipse(stock scheme) to ruby/textmate(vibrant ink) I was struck by how much I preferred reading the code in the bold colours of vibrant ink. Going back to java seemed dreary by comparison.

8 points by stock_toaster 14y ago

Many of the same arguments would apply equally well to removing whitespace and punctuation from natural language, something that many people today in some (even large) cultures--and certainly those living a thousand years ago who spoke many of the dominant languages at the time--would describe using "don't want". Color is just another axis along which information can be communicated to you, one similar to using bold fonts to indicate "this is a keyword" (which many textbooks do) or italics to mean "this is important" (which many articles do) or different fonts to indicate "this was block quoted from a typed document" (which many books do). It would actually be kind of interesting to set off proper nouns in a special color (and in fact some languages do this, both human and machine, using capitalized first letters), or to highlight pronouns in colors that matched their references (to make random access scanning in fiction books faster and easier). If the colors aren't working for you, you might want to figure out how color could be better applied to your problem, but throwing it out entirely is just having fun accepting and working around the challenge of a handicap: next you might try removing language features such as "classes" or even "functions/procedures" from your experience, as "real programmers" do not need these distractions and without them you will probably spend more time paying close attention to your control flow. (In fact, while that sounds silly, spending a few months coding in nothing but assembly language is actually quite mind-opening.) (Also, FWIW, Rob Pike--the inspiration for this article--actually makes arguments similar to this for why Go is a great language: that by having fewer features, people will make less mistakes... very similar to the reasons why people designed Java as limiting as it is, and why thousands of developers insist on using C instead of C++ or assembly instead of C.) (<- All of this typed without the usage of paragraph breaks, as I'm certain that without them people just pay more attention to the argument structure ;P.)

stock_toaster 14y ago
I think the difference with your example of bold and italic text is different because they are occasional, so they are more signal than noise. They stand out as different because they are. I see quite a few color themes where everything seems to be a different color -- the signal of color almost gets lost in the noise. So I think I disagree with the author of the linked article to the extent he takes it. However, the article has made me wonder if a much simpler color scheme that highlighted strings and syntax errors only, would be a bit more straightforward and more signal than noise.

ollysb 14y ago

I'm not sure I buy this. Reading a book for example, you always read a book linearly. When I'm reading code I'm looking for different details at different times, I'm doing a lot of scanning. Sometimes it's functions, other times variables, strings etc. but being able to scan only items in a particular colour really speeds up my search. Syntax highlighting really helps with this. I'm also not sure about the idea of trying to hold more code in your head. Over the last few years I've changed my practices so that I don't have to hold much information in my head. For me this is one of the key benefits of TDD for example. At this point I find context switching easy to do because I've externalised the majority of my process to tools and practices. If anything, good syntax highlighting makes code a real pleasure to read. Coming from java/eclipse(stock scheme) to ruby/textmate(vibrant ink) I was struck by how much I preferred reading the code in the bold colours of vibrant ink. Going back to java seemed dreary by comparison.