
:syntax Off - qznc
http://www.kyleisom.net/blog/2012/10/17/syntax-off/
======
haberman
If you follow this reasoning I think you'd also have to shun line breaks and
indentation. After all, natural language doesn't put each sentence on a
separate line, or indent clauses. It flows in uninterrupted prose with
paragraph breaks being the only distinguishing horizontal or vertical
formatting.

Clean code is all about structure. Anything that help show structure,
symmetry, hierarchy, or other patterns is bringing your reader one step closer
to understanding. The difference between a keyword and an identifier is part
of the program's structure. Coloring it makes it visual.

Also, properly-implemented syntax highlighting is essentially a very short
feedback loop with the compiler that shows you how your code is actually being
parsed. Short feedback loops make creativity easier (this is the basis of a
lot of Bret Victor's work).

I agree with the author that "paying attention to what the code is doing
instead of the individual elements" is important, but I don't think you have
to turn off syntax highlighting to achieve this. At least I don't personally.
If the colors are distracting, one idea might be to make them more muted so
that they don't demand as much attention. But to me there's no going back from
being able to see visually that you forgot to close a string or parenthesis,
or include a proper line continuation for your macro.

~~~
evoxed
> If you follow this reasoning I think you'd also have to shun line breaks and
> indentation.

Not quite. As I'm sure you know, written languages have evolved over time in
order to meet the needs of readers and writers alike. That includes
capital/lowercase, roman style (i.e. non-script) lettering, _spaces_ , leading
and paragraph indentation (thanks to printers), etc. It isn't helpful to
blindly latch on to seemingly cute analogies, but in this case I think it's a
pretty fair comparison. I imagine others who don't use highlighting all the
time would agree that it's a happy or at least _comfortable_ middle ground.
I'm a little sleepy-eyed now and shouldn't still be typing, so sorry if my
tone reflects negatively. I think the response below (corwinstephen) brings up
the same thing, except if you like highlighting then your middle ground leans
further towards an explicit, notated style.

~~~
bmj
Further, if you write a list of instructions (say, a recipe), you will likely
follow a convention that puts each instruction on a separate line, and might
make use of indentation to further delineate sub-instructions.

------
doesnt_know
_> When I read a book, I don’t want parts of speech highlighted in different
colours. What I want to do is to read the book, to take in the information._

I actually think this would be a great idea and it would probably prevent me
from having to reread paragraphs every now and then because I thought the
wrong person was talking.

~~~
OriginalSyn
Yea color coding character's speech would allow for some interesting changes
in structure, for example, you could have characters interrupt another without
breaking the line making it much more fluid.

------
Jonanin
Although I think the article as a whole is insightful, I really don't agree
with the book analogy. Most of the time, one reads a book in a very linear
fashion - left to right, top down, hopefully with little interruption. With
code, I find myself having to jump around a lot more - to find where something
has been declared, or to look up a subroutine, etc. This means there is a lot
more searching for the relevant text in programming than in reading a book,
and syntax highlighting helps my eyes identify these parts on a line or a
block a lot more quickly.

However, I can see how turning off syntax highlighting could help one learn to
keep more code in their head at once, so they don't have to jump around as
much, but to me, it's not worth it.

------
Xcelerate
I tried this before. I used to write all of my code without syntax
highlighting -- for years. Once I switching to highlighting, my errors
decreased, my productivity increased, and I was a lot happier. To each his own
I suppose.

------
jpadvo
Interesting. Both what Kyle talks about, and also the fact that I've never
thought of _not_ having syntax highlighting before. It's just been a built in
assumption.

I opened vim and cycled through syntax on, syntax off a few times, and thought
about what I think about when I see it. After this short experiment, I think
that most of what I use syntax highlighting for is just to add texture to the
code. The pattern of indentations and syntax highlighting gives the code
shape.

So when I scroll, or scan the code, I've got another a set of visual anchors
in addition to the structure given by indentation. It makes me feel more
comfortable. Past that, for me, the syntax highlighting is just noise.

Makes me wonder how to increase the feeling of visual structure in the code
without introducing visual noise...

------
drothlis
Something I've found useful is to highlight (in bold) the _definitions_ of
variables & types, but not their uses; and to otherwise have very little
highlighting:
[http://david.rothlis.net/code_presentation/distracting_synta...](http://david.rothlis.net/code_presentation/distracting_syntax_highlighting/)

~~~
calinet6
This just made me think that highlighting would be way more interesting if you
could change the scheme on the fly. An editor could have 5-10 highlighting
schemes—not different colors, but different kinds of information shown
(because let's face it, highlighting is valuable information).

Examples I just thought up:

* Variable-scoping-level highlighting—variables in the same scope highlighted the same color.

* "String only"—highlight only strings and literals. Check for language bugs.

* grep-only highlighting—define a set of things to grep for quickly and highlight them.

* block-focused—highlight code blocks so you get an idea of the overall structure of your program.

* No-highlighting: if you really want a moment of clarity on your code. There is absolutely no reason to give up the information highlighting provides 100% of the time, but I could see it being useful sometimes when you need to focus.

And countless more. If I could switch with a quick keyboard shortcut to a
highlighting scheme appropriate for any given programming task, it would be
phenomenal. I could see it being useful for all kinds of things, and helping
to show more information from the compiler than syntax highlighting does
already, in a better way. It would be instant visual information, and there's
no reason to limit it to syntax like we do currently.

Hmm. Sublime Text Plugin perhaps?

~~~
drothlis
> Variable-scoping-level highlighting—variables in the same scope highlighted
> the same color.

I played with this idea in the syntax highlighting of the code samples in this
article: <http://david.rothlis.net/c/compilation_model/#chapter005>

but would you want all variables at the same scope in the same colour?
Different colours for each variable, with the darkness/lightness indicating
the scope?

> grep-only highlighting—define a set of things to grep for quickly and
> highlight them.

Emacs has this with the "highlight-regexp" command. To be honest I don't use
it that much. What I do like is highlighting all matches whenever you're doing
a "find in file" (though unlike highlight-regexp, the highlighting disappears
as soon as you exit the search). I probably use this more because I use search
all the time (who doesn't), whereas I tend to forget that "highlight-regexp"
even exists.

> block-focused—highlight code blocks so you get an idea of the overall
> structure of your program.

A few examples of how this might look:
[http://web.archive.org/web/20080723220126/http://lemonodor.c...](http://web.archive.org/web/20080723220126/http://lemonodor.com/archives/2005/08/five_approaches.html)

> No-highlighting

In Emacs the "font-lock-mode" command will toggle all highlighting; and you
can specify the "level" of highlighting you want by setting the "font-lock-
maximum-decoration" variable (you could set up a specific key to toggle this
variable). I think these levels were originally intended for performance
reasons, so they're cumulative (enabling level 3 also brings in all the
highlighting from levels 1 & 2) rather than individually-toggleable features.

I only bring up Emacs because that's what I'm familiar with, and because I'd
like more people to experiment with these types of things in Emacs. But
perhaps Sublime Text would be a better platform for such experiments, for some
people; I don't know.

------
bilalq
I write a lot of code on whiteboards or paper as well, but I could not bear to
part with syntax highlighting. When you're off the machine, a missing quote or
semi-color won't cause the whole thing to come crashing down. The same can't
be said for when you're actually typing things.

As the author already mentioned, strings are really annoying to work with when
you don't have syntax highlighting for them. I would group comments in the
same category. It's difficult to see where they begin and end without the
visual cues provided by syntax highlighting. That can quickly become a
disaster.

I did try out going through code just now without syntax highlighting. New and
short programs weren't bad at all, but going through files with hundreds of
lines quickly became a challenge. This might work for the author, but it's not
for me (nor, I suspect, for most people). Colors and font styling make it easy
to get a grasp of what's going on. Taking that away does reduce noise, but
cuts down far more on signal.

~~~
pyre
I imagine that it has a lot to do with the language too. Things like Perl,
Ruby or even shell scripts have a lot of syntax that benefits from syntax
highlighting (I'd say most of them related to strings and string
interpolation), while C maybe doesn't.

------
twiceaday
This is how that page looks like on my computer

<http://i.imgur.com/x8kqM.png>

Windows 7, Chrome 24.0.1312.2 dev-m

~~~
xentronium
Yet another case of chrome's bad rendering.

The font used: <http://www.google.com/webfonts/specimen/IM+Fell+English>

Why would anyone try and use bad typewriter font imitation on a website is
beyond me.

~~~
petercooper
More like Windows' bad rendering. It looks fine in my Chrome on OS X. A bit of
a lame font but readable and not all flaky like the Windows screenshot linked
by the original commenter.

~~~
joshuacc
Chrome renders fonts differently than other browsers in Windows 7. Possibly
for speed reasons? Both the latest FF and IE9 look decent.

~~~
pcwalton
It's more historical at this point. Chrome doesn't use DirectWrite because it
uses Skia on Windows. At the time, the choice was between GDI+ and Skia, and
Skia was much faster. But DirectWrite on Vista and 7 is extremely fast (it's
GPU-accelerated, unlike the Skia backend Chrome uses).

------
bti
I remember when I first started to program I used Notepad.exe to write the
source in. It was all I knew at the time and it worked. The day I discovered a
text editor that did syntax highlighting was amazing, finally I could see at a
quick glance any obvious errors in my code as well as the structural elements.
This is far too ingrained in my workflow to consider removing it but I may
give it a try. When I do write plaintext I usually do it in a light
colorscheme (Solarized Light) and it does read more like a book.

The author makes the argument that removing highlighting forces you to be more
careful with the code you write. Removing three of my fingers would also force
me to be more careful, but I'll take everything I can get to make me more
productive.

------
nfm
To each their own, but I'm having real trouble imagining that this could
actually be helpful!

I'm sure it's possible to get used to, but I doubt I'm the only one that
remembers when they first turned syntax highlighting _on_ , and the difference
it made to my productivity then.

------
SwellJoe
I'm always surprised when I meet folks who prefer not using syntax
highlighting. At some point the surprise will go away, but for now it's still
pretty darned rare. The first person I met who expressed a strong preference
for no syntax highlighting was Matt Trout (mst here at HN), who is certainly
productive enough to provide a compelling argument in favor of it.

I might even try it again one of these days.

~~~
pyre
I find it interesting that mst isn't into syntax highlighting as his main
language (Perl) has string interpolation. Making sure that variables embedded
in a string stand out can be important:

    
    
      "Number of Records: $numrec\n"
      "Number of Records: \$numrec\n"
      "Number of Records: ${\ get_number_of_records() }\n"
      "Number of Records: \${\ get_number_of_records() }\n"
    

Or

    
    
      my $string = <<"    HEREDOC";
      my $name = "Thompson";
          HEREDOC
    

It's much less important in something like C where you would just being using
something like sprintf().

~~~
SwellJoe
Perl is also my primary language, and it is partly why I like highlighting. It
may state something about the opinions of the programmer; perhaps that complex
interpolations in strings, among other things, might be a code smell they
don't like, and avoid. Having no highlighting would remind you not to do that
sort of thing.

I think the sigils alone are sufficient to flag variables in strings...but
when things get complicated and span multiple lines, it can become ugly and
difficult to work with. But, I'm not convinced this is the most useful
function of highlighting in perl (again, because the sigils already provide
visual clues)...it think it's more useful in pointing out unclosed parens,
brackets, quotes, etc., and letting you know your syntax is wonky.

That said, it may be laziness on my part. I find it soothing to have
highlighting enabled, and I get nervous when it's not, as I'm never quite sure
I've got the syntax right until I check it.

------
evoxed
I agree with the author that turning syntax off is like reading a book. When I
read in English, I don't want to be bombarded with color or style changes that
aren't completely necessary. I appreciate their function as an aid to
recognizing patterns, but I've read enough so that I can glance at the entire
page and recognize all the patterns I want in a few seconds. Now, when it
comes to reading books in a foreign language (e.g. japanese or mandarin) it
can be a tremendous aid while you're learning because it helps you make sense
of where the breaks are in something that might otherwise take a considerable
amount of time to break down bit by bit. As soon as you start getting used to
it the patterns become obvious on their own, and the visual aids just become a
layer of noise.

My main exception is comments, or footnotes on the side. At a quick glance
it's very helpful to skim through a file and see what's documented or, if it's
a text/config where each section break is.

Edit: after skimming the other comments here it seems that the preference for
highlighting is more to do with error checking than anything (pairing
enclosures, etc.). If that's the main concern then why not zap the rest and
use syntax the same way you'd use spell? I don't use highlighting for much but
I might just drop that into my vimrc tomorrow to play around with it. I would
rather see glaring red blocks where there are mistakes than a minor variation
in my digital bowl of lucky charms.

~~~
Evbn
Syntastic for vim.

------
tikhonj
It's an interesting idea.

I've actually gone the opposite way recently. In the past, I'd only have code
highlighting. Different parts of the syntax would be rendered as different
colors--nothing surprising.

However, recently I've been writing a lot of Haskell and OCaml. At least in
Emacs, both Haskell and OCaml have an additional option to syntax highlighting
with color: your code can also be highlighted with _symbols_. That is, parts
of the syntax are not only displayed in a different color but actually
displayed as a Unicode character rather than ASCII. As a moderately contrived
example, something like

    
    
        \ a b c -> a >= b && b <= c || a /= c
    

would get displayed as:

    
    
        λ a b c → a ≥ b ∧ b ≤ c ∨ a ≢ c
    

Now, real code doesn't usually have symbols quite as dense; this example just
shows a whole bunch of them at the same time.

I find the second snippet far easier to read than the first, especially if I'm
just scanning over the code.

This is also a very good reason for using a typeface like Deja Vu Sans Mono:
it can support all the symbols I could ever want. It's also very readable.

I personally find this, combined with syntax highlighting, extremely useful
for reading code. Actually, thinking about this, I've found syntax
highlighting even more useful for Haskell and OCaml than other languages,
probably because they have very minimalist syntax. I really like the syntax,
but the color does make the overall structure of any given function much more
evident, which is nice.

Coincidentally, for the same readability reasons as above, I'm significantly
warming up to Unicode identifiers. I think something like:

    
    
        set1 `union` set2
    

is not nearly as readable as

    
    
        set1 ∪ set2
    

And, as a bonus, the second version is easier to type:

    
    
        set1 \cup set2
    

Additionally, using Unicode identifiers and operators matches the way I write
pseudocode. With the right identifiers, my Haskell code actually looks very
close to what I would write on a whiteboard to explain some concept. That's
one of the reasons I really like Haskell's syntax.

As an aside, the expression

    
    
        set1 `union` set2
    

is a perfect case study of why I find syntax highlighting useful. First of
all, I think it's strictly better than the prefix version:

    
    
        union set1 set2
    

I've found being able to use arbitrary functions in an infix position can
sometimes make certain expressions much more readable and natural.

However, if you're just scanning over the code, it might be easy to miss the
backticks. Happily, in Emacs, operators get highlighted in a different color
from normal identifiers. This includes things in backticks. So the `union`
gets highlighted in a different color, making it obvious it's being used in an
infix position.

~~~
yfr
This is amazing! Any idea if this is possible in vim?

~~~
tikhonj
There seems to be a plugin called unicode-haskell[1] for Vim. However, as I am
obviously not a Vim user, I don't really know anything about it.

[1]: <https://github.com/frerich/unicode-haskell>

~~~
wladimir
I wouldn't recommend using that one. There is a newer plugin [1] that uses
"after" in combination with conceal syntax to achieve the same effect but
without buffer hacks on load/save.

[1] <https://github.com/vim-scripts/Haskell-Conceal>

~~~
threedaymonk
Haskell-Conceal also works a lot better than unicode-haskell: it doesn't
erroneously turn "\n" into "λn", and it replaces :: with a single-glyph
equivalent so that signature and definition line up nicely.

Having said that, I still prefer <\- and -> to ← and →, at least on screen:
those Unicode arrowheads are too small on all the fixed-width fonts I've ever
seen.

~~~
wladimir
Those arrows are indeed pesky. In my fixed-width fonts (at least at the font
size I'm using), → (->) and ⇒ (=>) look the same.

------
cdmoyer
Interesting. I've done a fair amount of coding without syntax highlighting,
particularly on live web servers ( _gasp_ ) without my vimrc.

What I find is that I don't really rely on syntax highlighting for find my way
around the code or understanding it. I rely on it to tell me when I didn't
properly close a string literal, or a comment, or fat-fingered a keyword. So,
I generally enable it when I can, and find that it makes me more productive.

------
pfortuny
When you read a book you do not need to be consciously aware of the syntax
(unless it is either patently bad or extraordinarily original). When you are
programming, most of the time you are dealing with syntax more than meaning...

In the end, what the logicians of the XXth century taught us is that logic
(read maths/cs/...) is just syntax (from the formal point of view, mind you).

------
sliverstorm
Perhaps when you're _writing_ code, you are using it as a crutch. (I'm not one
to know, really)

However, I certainly feel when I am reading someone elses' code, it is not a
crutch but a tool. The highlighting helps me see an unfamiliar program's
structure just a little more easily, which is nice when you're absorbing a
couple hundred lines with sparse comments.

------
spottr
While I read a book I take notice of headers providing logical partitioning,
page headings & numbers for orientation. On paper text may also be set with
bolder font, or with emphasis added. It helps, when done _properly_. Same with
syntax highlighter. I don't want to re-read entire screen of code every time I
need to make a change in this general area. I want to have mental model
"indexed" upon the looks of code. This can of course be done on "plain" code,
but it's slower and I can only hold my attention for so long each day -- why
waste it, especially if I need to specifically disable some features of my
software? And lastly -- code is not a book. I will read a book once, maybe
twice if I really like it (my max being 8 repeats), but there is never time to
read it again. While code? I will be read it for the rest of my life, as far
as I can tell... I will not enjoy reading everything for a 1000th time, that
much I know.

------
vitalique
May just be the case of a bad luck or not fidgeting enough with trying to find
a colorscheme to one's taste. I have several colorschemes - not ideal, but
decent enough to love and use - that I switch between depending on room
lightning and language.

Book comparison is far-fetched imo. Code is not just a regular text, it's a
very structured text, and reader of a structured text benefits from structure
hints (expressed via color and identification), while writer of such a text
benefits even more from on-the-go error checking. Looking through a dictionary
without any bolds, italics and structure, just paragraphs and paragraphs of
text, would be a waste of time and a pain to the eyes. And this is what I tend
to do about 95% of time when 'writing' code - looking at it.

I would recommend searching for a less contrast or vibrant colorschemes like
popular Solarized (too low contrast for me actually) or Tomorrow themes.

------
gurkendoktor
There are more options than just "monochrome" and "syntax highlighting": For
example, Xcode 4 assigns all identifiers taken from the current project a
greenish colour whereas everything else (system headers/frameworks) are shades
of violet. I just wish it would understand that CocoaPods are not project code
:(

Another example, TextMate highlights some syntax _errors_ much more than it
highlights syntax- type "else if" in a Ruby file and it's bright red. How is
that not useful?

My love for syntax highlighting probably goes hand in hand with my love for
natural language operators. "if foo and bar then qux" is much harder to parse
without colours than "if (foo && bar) qux". Does anyone use a monochrome
editor _and_ natural language wherever possible?

------
kellishaver
I used to not like syntax highlighting, but then I started writing more
complex, lengthier code in a variety of languages.

Instant feedback for error checking aside (which is incredibly useful) I like
the "texture" syntax highlighting adds to the code.

Indentation is great for organizing code into individual chunks, but if it's
all the same color, I find that it still starts to feel a little overwhelming
when the code starts getting long. Colors help create a visual flow and, at
the very least, break up the monotony, thus prevent the "wall of text"
effect.... which is fine for a book, but source code isn't a book. It doesn't
function like a book, you don't interact with it like you do a book, so it
really shouldn't look like a book.

------
jff
I started out writing code in Emacs, with highlighting turned on. I loved it
and couldn't deal with an editor that didn't have highlighting. At some point,
I started using Acme a lot for working on Plan 9. I ended up doing a bunch of
work on a variety of Unix boxes, and it was simpler to just use Vi without
highlighting than to set it up everywhere. I got used to not having it, and
realized I was pretty happy without it.

Plus, it always seems that whether I have light-on-dark or dark-on-light
terminals set up, one of the colors is so off that e.g. strings become
essentially invisible (dark blue text on black background) and it's easier to
just shut off highlighting than to fix the highlighting.

------
danielatc
Interestingly there is something like syntax highlighting in natural language
too. One example is that all nouns in German are capitalised which helps a lot
in the context of ambiguity. To give you an idea of a case in which it
actually might help:

    
    
      The complex houses married and single soldiers and their families.
    

vs.

    
    
      The Complex houses married and single Soldiers and their Families.
    

Other languages use different markers to indicate different parts of speech.

A point that could be made is that (written) language evolved for a long time
and the concept of "syntax highlighting" is embedded in at least some of them.
Probably because it has proven useful.

------
thomasfl
First hardcore developers where shifting from IDE's to vi and emacs. Now
hardcore developers are turning off syntax coloring? What' next?

~~~
voyou
Hardcore developers will start using ed. It allows you to focus on one line at
once, with none of the distracting "context" of screen editors.

------
jazzychad
I did the same several weeks ago at work. I turned off syntax highlighting in
XCode for doing objective-c coding. More specifically, I created a theme with
all the same color:
<http://dl.dropbox.com/u/68874506/Screenshots/xcodeterm.png>

I'm used to coding in terminal screen sessions, and using an IDE is a bit too
shiny for my liking so I created my own terminal for XCode :) Now when I look
at my co-worker's color-coded ruby code in Sublime Text it looks like a bunch
of unreadable rainbows.

Colors are pretty, but since I turned them off I found that I haven't missed
them. They turned out to be distracting, and I can't remember a situation
where the colors helped me scan the code faster to help me find something. One
color means I now treat all tokens equally.

~~~
jff
Can I suggest trying a light grey font on that dark background, or even better
(in my experience) black on white or very mild yellow (see Acme). In my
experience, when I use green on black too long, I see purple when I look away.

------
wladimir
What I found an interesting development in syntax highlighting is "semantic
highlighting". Some IDEs support this by integrating directly with a compiler
(such as clang).

At a primitive level it allows, for example, coloring nams of variables either
by type, or by source (local/field/static field), same with function names
(ie, is it a function, method, a static method, etc). See for example:
<http://doc.qt.digia.com/qtcreator/creator-highlighting.html>.

But I'm sure much more is possible. Semantic highlighting could help
understand the (non-local) semantic structure of the code, and allow finding
mismatches between what the user intends and what he has specified.

------
zokier
[http://www.linusakesson.net/programming/syntaxhighlighting/i...](http://www.linusakesson.net/programming/syntaxhighlighting/index.php)
here is another one advocating the same thing.

------
dools
I write code with syntax highlighting turned off. Syntax highlighting has
always given me the shits - it's noisy and distracting and I don't need it
anyway.

The only time I :syntax on is if I get a parse error and can't find the
culprit quickly, and it's probably a problem with string being constructed
incorrectly (I mostly work with PHP so something like 'and that's that';). In
that case having the syntax highlighter to tell me where the string
interpolation goes awry is very useful, but I turn it off again once the
problem is fixed :)

------
btipling
This idea strikes me as appalling, but I'm trying it. I turned off syntax in
vim just to see what it was like. I toggled back and forth a couple of times
and found the syntax highlighting valuable, but without syntax highlighting it
was still readable.

Now I've turned off syntax highlighting in vim and zsh and my irc client. Just
to see what it's like. Will try it for a few days.

------
arnarbi
The choice of font for the blog's body text doesn't lend the author any
credibility on this topic.

For what it's worth, I tried both syntax highlighted and not - and the former
results in a measurable improvement in productivity. I believe experimenting
with tweaking one's tools is worthwhile in most cases.

------
jamesaguilar
I have wondered for some time whether syntax highlighting really adds
anything. Intuitively, it ought to . . . but has anyone ever tested this
rigorously? I'll give it some anecdotal testing tomorrow and see if I regret
it.

~~~
fbuilesv
See this code:

    
    
      <%= render partial: 'user, collection: @user.followed_users  %>
    

I see (and write) errors like this all the time. Turning :syntax on saves me a
browser refresh/compile cycle/spec run every time. Not sure if I'd need a
rigorous test to tell me how helpful it is :)

~~~
jamesaguilar
Ah, my editor has separate error highlighting, so I don't have to forgo that
immediate feedback to turn off syntax highlighting.

------
auggierose
Lol. That can come only from someone who actually uses vim when something like
Emacs exists.

~~~
EvilTerran
<http://ycombinator.com/newsguidelines.html>

_Please avoid introducing classic flamewar topics unless you have something
genuinely new to say about them._

