

Syntax Off (2012) - luu
http://www.kyleisom.net/blog/2012/10/17/syntax-off/

======
ketralnis
> Syntax highlighting had, for me, been somewhat of a crutch. I was relying on
> it to immediately highlight code errors

One man's crutch is another man's perfectly reasonable tool. Is a carpenter's
level a crutch?

> When I read a book, I don't want parts of speech highlighted in different
> colours

I have trouble discerning colours and I still use syntax highlighting. I don't
think that there are people that are programmers but unable to read code
unless all of the floats are purple. The highlighting mostly just tells me
"this parsed correctly" and helps my eye track where e.g. string literals
begin and end. I don't really see a reason to give either of those things up.
If it's distracting, you could easily turn down the theme to just bold one or
two keywords and string literals, which solves both of those two problems at
least. Maybe go crazy and reverse the background on obvious syntax errors like
unexpected symbols.

I rarely want to focus on the code itself and more just want to focus on the
problem. Immediately highlighting code errors seems like a perfectly nice
thing to do to that end. If I could just write a bunch of code quickly,
riddled with syntax errors, and click some magic "okay editor, fix away!"
button I'd be fine with that too.

To each their own I suppose.

~~~
zeroDivisible
I don't know why, but when I was reading this, I had in my mind that
submission from earlier today, what 4chan thinks about HN, especially this
bit:

"How I stopped [perfectly fine activity]... And why you should, too."

------
Shish2k
"When I read a book, I don't want parts of speech highlighted in different
colours"

I do! In long conversations in novels I occasionally lose track of who is
currently talking; normally it's really obvious as the next page of text
doesn't make any sense until I backtrack to find where the speech got
switched, though one time I finished a whole book where my protagonist had the
wrong gender because I didn't realise that the prologue and the main text were
written from different people's first-person perspectives...

It also reminds me of some anime fansubs, where series with lots of characters
would have each character's subs written in their hair colour, which is really
helpful for someone who has trouble disinguishing similar foreign voices from
each other :P

~~~
vorg
> In long conversations in novels I occasionally lose track of who is
> currently talking

Perhaps the actual story narrative needs to be clearer, by repeating the
speaker's name more often.

~~~
snogglethorpe
It's amazing how often fiction doesn't even indicate the speaker _once_ (in
any given dialogue), and just leaps into conversations by simply starting
them, relying on context and "voice" to identify the speaker, alternating back
and forth with other speakers with no intervening description.

I don't seem to have much problem with this in English, but it causes me no
end of grief reading in a non-native language, I suppose because my grasp of
context and eye for other cues is much shakier...

[I've read books where I'll get halfway through the book before realizing my
_entire conception_ of what's going on has been completely wrong due to
confusion over who said something in the beginning of the book... I'll go
back, re-read the crucial dialogue with the speakers swapped, and suddenly
_everything_ starts making sense... TT ]

------
ChuckMcM
TL;DR - no syntax highlighting means you have to read the code to avoid syntax
errors, and that keeps it more present in your head.

Which is true, we used to joke that the C compiler on a VAX was so slow that
you wanted to be really really sure it wasn't going to throw some crappy
syntax error so you read through your code twice before submitting it. But a
friend of mine from the Amiga community showed me that iterating fast often
lead to faster code development than slower iteration. In both cases having
your code in your head made for a better result, but someone who could iterate
fast and hold the code in their head, always out performed the person on the
slow path.

It can be hard to develop the discipline though.

------
trevvvor
Traffic lights should be monotone and drivers should just know what position
means what.

Whatever metaphor you use, this is just dumb.

~~~
thenerdfiles
This.

------
thedz
> When I read a book, I don't want parts of speech highlighted in different
> colours

Books don't have syntax highlighting, but having never read a book that does,
I can't say one way or the other that it is a terrible idea.

And actually, as I think about it more, books _would_ be a nicer reading
experience if conversations were highlighted, and if key person/place names
where in a different color.

(Just like text in RPGs sometimes).

~~~
gliese1337
There is one book I know of which uses text color significantly: Michael
Ende's _The Neverending Story_. It's very coarse-grained- the color just tells
you whether currently-described events are in Fantastica or The Human World-
and I don't know if it actually assists in reading comprehension or anything
like that, but it _is_ a joy to read.

As a personal note, the first time I read it, I didn't realize that the colors
were significant for a couple of chapters because, for some reason, I
occasionally perceive black text on paper as being red, and thus it took me a
while to realize that this text _actually was_ printed in red.

------
northisup
Syntax highlighting is our engineered Synesthesia.

> "The best way I can describe it is to compare it to reading a book. 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 would love to try reading a book with the same support. Nouns in red and
adverbs in green. It would be fantastic! So much passive information
available… Now I think I know what my next weekend project is.

[http://en.wikipedia.org/wiki/Synesthesia](http://en.wikipedia.org/wiki/Synesthesia)

~~~
vorg
Some natural languages capitalize nouns, e.g. German. Japanese uses kanji for
noun, adjective, and verb stems, and kana for grammar words and inflections.

------
jpollock
Ever since I spent a week wondering why my main loop only ran 3 times, I
always turn syntax highlighting on.

This is what my code looked like:

    
    
      // Initialise
      for (i=0;i<3;++i) {
        /* Do initialisation here!
        niftyConfig = 1;
        funkyValue = 2;
      }
    
      // Run forever
      for (;;) {
       /* So, this is where we do stuff! */
      ...
      }
    

Syntax highlighting would have shown the problem instantly. In fact, the bug
would never have happened.

Anything that can increase the chance to catch an error is a good thing.

[EDITED for code formatting.]

~~~
_sigma
This is a fantastic example! Took me having to turn on code highlighting to
catch it.

------
egork8n
I think turning syntax highlight off is too radical, you can get all the
benefits mentioned in the blog post by using colorschemes like zazen or
zenesque.

* zazen: [http://www.vim.org/scripts/script.php?script_id=3413](http://www.vim.org/scripts/script.php?script_id=3413)

* zenesque: [http://www.vim.org/scripts/script.php?script_id=3340](http://www.vim.org/scripts/script.php?script_id=3340)

------
jlgreco
Here is another popular article about not using syntax highlighting.

[http://www.linusakesson.net/programming/syntaxhighlighting/](http://www.linusakesson.net/programming/syntaxhighlighting/)

I still think it is nutty.

~~~
akkartik
My synthesis of the acme/plan9 folks and the mainstream is that color can be
useful in an environment, but the way it's currently used is not. Like this
guy points out, there's no point highlighting language keywords; we're just
doing it because it's easy to do so. Rather conserve the color and our
attention for when it's truly needed.

But the need for color seems too strong to fight with pure rationality.
Perhaps it's enough that adding a little color to an environment we spend a
significant amount of our lives in makes us happy. Since I have no taste,
garishness doesn't bother me :)

Here's an example of color being used in a relatively staid place -- and
paying for itself:
[https://plus.google.com/110440139189906861022/posts/UqyUZdqP...](https://plus.google.com/110440139189906861022/posts/UqyUZdqPVbr)

Hopefully these considerations will be subsumed by new research by Bret Victor
or Rune Madsen ([http://vimeo.com/61113159](http://vimeo.com/61113159)).

For now, here's my preferred syntax highlighting, with just a dash of color in
most usual places, but _two_ colors for comments:
[http://i.imgur.com/H1h7M.png](http://i.imgur.com/H1h7M.png). (Why 2 comment
colors?
[http://akkartik.name/post/2012-11-24-18-10-36-soc](http://akkartik.name/post/2012-11-24-18-10-36-soc)
has the scoop.) Notice how the left pane is C++ and the right pane is my toy
lisp, and the syntax kinda harmonizes.

~~~
jlgreco
I have little objection to some people preferring fewer colors or having fewer
things called out for coloring. What I don't understand is the leap from _"
This particular scheme is totally overdoing it"_ to _" Let's discard the
notion entirely"_ Merely adjusting the colors that you use and the things that
you highlight seems like a clear winning solution.

------
tikhonj
I've found syntax highlighting is good at making the _structure_ of code
evident, which in turn makes it much easier to grasp the general idea of a
snippet at a glance. This is a very important property!

Code is read more often than it's written, but it's _skimmed_ more often than
it's read. So making it easy to mentally jump around code without actually
reading it is extremely valuable.

I've found this particularly valuable in Haskell because it lets you use
arbitrary things in infix position. Now, this by itself is valuable for the
same reason: it helps structure the code, neatly separating the operation from
its arguments. Some things just make more sense infix. But visually, it's
often hard to grasp when something is infix. This is not _too_ bad with
operators:

    
    
        foo bar baz + qux 11 quux
    

but it's actually rather difficult with normal words infix:

    
    
        map solve problems `using` rpar rseq
    

Now compare this to the highlighted version: [http://jelv.is/img/hs-syntax-
hl.png](http://jelv.is/img/hs-syntax-hl.png)

The most important part of the above snippet is how "using" divides into two
clear parts. And yet, on something like HN, this is a bit hard to follow:
"using" looks like another word in a string of words--this is exactly what I
want to avoid with the infix syntax!

In Emacs, at least, infix symbols--both operators and names in backticks--get
highlighted in a different color. This _immediately_ make the structure of the
above code completely clear. Then, when I'm glancing through it, I can focus
on the part I care about. (This example is particularly appropriate because
the two halves do completely different things--the left one defines the
computation and the right one specifies how to parallelize it; chances are I
only care about one of the two at a time.)

I think that highlighting operators also explains why I've never had any real
difficulties with Haskell's "symbol heavy" code.

This could be extended to a bunch of other structural distinctions I care
about. For example, when reading Lisp code, I would love to have macros and
functions highlighted differently. Macros generally represent some sort of
code organization where functions are often part of the actual program logic;
moreover, macros and functions behave very differently.

------
jzelinskie
This reminds me of something I've heard Douglas Crockford propose in the past:
syntax highlighting would be more useful [in some languages] if it was used to
color different scopes.

~~~
jwarren
I already do this in Sublime Text, it's very useful when you may have PHP and
HTML in the same file. It's also useful with the much less common HTML with
CSS or JS.

~~~
oneeyedpigeon
I fear you're about to get a lot of comments about mixing PHP and HTML in the
same file. And I don't think the OP was talking about that kind of 'scope'.

------
recuter
I actually sometimes associate words with sound and color - it makes me wonder
why we are still limiting ourselves only visual feedback.

I vaguely remember somebody posting a lisp-y emacs-y setup of a synth coding
environment of sorts that looked like heaven to me. (You'd quickly iterate on
code with transforms that would shift the sound playing at all times and the
colors would POP at you) It also makes me wonder how blind coders handle
things. Does a pleasant yet distinct background noise when hovering over say,
curly braces or parens, does that make sense to anybody else? I'm developing
an itch here but I don't want to go it alone as it were.

Edit: also come to think of it, why isn't this stuff empirically tested? The
right font faces and sizes for optimal readability, tabs vs spaces, camelCase
vs snake_case, colors and which ones, all the classics. Where is the science?

~~~
bcj
Interesting in theory, though it could get annoying fast (The first thing I do
is always to turn off the bell).

Changing tone based on depth could be pretty interesting, as could tones
representing things like unused variables.

Based on your preferences, you could also do things like have the noise grow
unpleasant if you do something you shouldn't (e.g., reuse a variable name,
write an impure function, etc.).

------
bcj
"The best way I can describe it is to compare it to reading a book. 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 found this interesting, as my reaction has been almost the complete
opposite. I've never felt that syntax highlighting played a part in
understanding code at a high level. Syntax highlighting is there for when I'm
reading my code like a copy-editor. It (along with an inline linter) is there
to make syntactical errors more obvious so I can deal with them as I make
them.

~~~
oneeyedpigeon
I think this analogy is just terrible. A book != code. Well, certainly a
novel, in which you're not re-reading the same sentence several times over,
flipping 100 pages forward, then 90 pages back, etc. I can actually think of
certain ways in which a non-fiction book could be usefully 'syntax
highlighted'.

------
xytop
It reduces productivity and adds headache. Code is not a textbook. A good
programmer has to always look at different pieces of code and would lose
himself in the mess of symbols if there is no indents and block highlights..

~~~
Jtsummers
Well, even textbooks often use colors, fonts, emphasis and other mechanisms
for the same thing we use it in syntax highlighted code.

And if he's meaning to compare it to prose, while they typically lack color
(due more to the means of printing than the format, check out old manuscripts
and they use color quite often), they use punctuation and other methods of
emphasis like bold, italics, size, and underlining.

------
larrybolt
I believe this is worth thinking about, because if the syntax highlight is
only to disguise whenever the syntax is incorrect, you could only highlight it
when it is incorrect, and modern IDE's (vim including) are capable of doing
this.

On the other hand, perhaps highlighting the syntax is to represent the
structure of source code, or make it more readable. There is also a text
highlight utility for text, called BeeLineReader
([http://www.beelinereader.com/](http://www.beelinereader.com/))

------
_sh
Is using <h1> and <h2> tags syntax highlighting for text?

Personally I program Clojure, so there's not a lot of syntax to highlight--
well, more than in scheme, for example--but I couldn't imagine life without
brace matching (a dynamic kind of syntax highlighting).

~~~
Jach
A particularly useful plugin for a type of paren matching a lot of people
curiously don't know about is Rainbow Parentheses
[http://www.vim.org/scripts/script.php?script_id=3772](http://www.vim.org/scripts/script.php?script_id=3772)
(example:
[http://i.stack.imgur.com/Hlctr.png](http://i.stack.imgur.com/Hlctr.png))

------
vorg
> The lack of syntax highlighting was a bit of a shock at first, but I found
> over a day or two that I began to get used to it.

Once you're used to the lack of color, go all the way and use a proportional
font.

~~~
computer
Don't forget to drop the indenting as well.

------
agumonkey
unless you're writing color forth code
[http://blogs.msdn.com/b/ashleyf/archive/2013/11/02/colorfort...](http://blogs.msdn.com/b/ashleyf/archive/2013/11/02/colorforth.aspx)
in which colors have semantics.

------
kayoone
highlighting creates a picture of your code that the human brain can process
much quicker, thats why traffic lights or player jerseys have color.

------
dlsym
"How I stopped [perfectly fine activity]... And why you should, too."

~~~
dingaling
I've no problem with syntax highlighting as a concept, but invariably it's
only designed for white or black terminal. If you need to use something else,
like light gray, then certain colours of elements disappear due to low
contrast.

Much like the colour output of ls; beautiful on black, largely invisible on
anything else.

~~~
mixmastamyk
When changing the background, change any clashing colors as well. There are
premade themes in gnome, xcfe (and other) terminals.

