Hacker News Reader

Comment by pheroden | Hacker News Reader

I've been writing code professionally for 20 years, and as an armatur for 30. I can parse code much quicker if it has syntax highlighting. If you don't, that's fine, but it doesn't mean your more experienced or somehow better than those that do. I always hate conversations about this because it always seems to come down to a dick measuring contest where everyone seems to think that more monochromatic the longer it is. It's not. Use what feels right to you.

View on HN

> dick measuring contest

A more experienced colleague: "Pah, that's just a crutch". Well, yes. And?

My personal tipping point was watching a sysadmin edit resolv.conf and type "namesrever": vim picked it out in reverse red. This mistake could otherwise have gone unnoticed for a while. Good crutch.

When I first started writing python, my number one error was writing "else" without the necessary colon. A simple adjustment to my syntax highlighter and I stopped that class of error completely.

Other crutches: keyboards (just enter your data with switches), non-volatile memory (reload everything manually at power on), compilers (generate machine code by hand), etc.

If someone says "pah, that's just a crutch" in a dick measuring contest, it's safe to say that he has won.

I can parse code much quicker if doesn't have syntax highlighting... or so I thought until I tried a properly subtle colour scheme (offwhite with various dark foreground colours, as it happens). I wonder how many of the colour-objectors really object to inappropriate colours rather than to their existence. Pale blue on white, bright green on white, etc.

I'm also in the light background, dark text camp, when it comes to code at least. I think Visual Studio (using the light rather than dark or blue themes) has the colours just about spot-on for me, especially in the 2015 editions where they seem to have softened the palette a bit.

That said, I'm completely the opposite when it comes to the command line. I think colour coding can add a lot (ls for example) but it has to be light-on-dark or not at all. Funny how that works.

How that probably works is that with this distinction, you know at a glance which windows on your desktop are editor windows with code and which are command lines (or possibly editors that have suspended to the background to go to a command line).

It's ... meta-syntactic-highlighting for your entire desktop! Different types of windows are colored differently, just like different kinds of identifiers in one window.

Yeah I like syntax highlighting but prefer subtle colors. I do prefer dark backgound. "Solarized" scheme has been my favorite for a few years now.

Of the canned ones in Vim, what do you think of "fnaqevan"?

By the way, something is wrong: my Vim isn't responding to ":set background=light" (or dark). The colors change, but not the background.

Yeah. IMO, the particular color scheme matters. I think I'd get much more benefit, vs no highlight, from the color scheme I'm used to, than the one the researchers chose (somewhat arbitrarily).

I could easily spend an hour switching through color schemes, and have done so. It shows. My wife looks over my shoulder sometimes and says that it looks gorgeous!

I believe that the color scheme is crucially important; it's a form of ergonomics. Bad colors will lead to fatigue.

Certain choices are obviously bad, like hues that make comments or other elements almost impossible to read; insufficient contrasts and so on.

In [this talk](https://youtu.be/b0EF0VTs9Dc?t=15m2s) by Douglas Crockford he talks about syntax highlight being for kids - "that's something we put in our text editors for kindergarteners to do programming...I am more sort of a grown up and a professional programmer so I don't need to colours".

I found it weird he was so deriding towards syntax highlighting.

Low self esteem I'm guessing.

He is working backward from his own personal preference and working awfully hard to justify that as if he came to that conclusion for logical reasons.

People often think they are acting logically when frequently they are working backwards to write narratives that justify the way they choose to act.

I wouldn't even think about releasing a programming language without an accurate syntax coloring definition for at least one major editor, maintained side by side.

Looking at code without coloring is like looking at a road atlas that has been photocopied in black and white.

Even some grayscale cues are better than nothing.

I actually run the Vim editor dynamically out of Apache to colorize TXR files. You can see that here and here:

http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/struct...

http://www.kylheku.com/cgit/txr/tree/tests/010/align-columns...

The second example shows a mixture of two languages: a Lisp dialect and an extraction language. Both have their own sets of standard symbols (which intersect: there are some symbols in common). They are correctly rendered in a different color: the Lisp words are green, and the extraction language words are burgundy red. This kind of thing is very helpful.

The Vim definition I maintain is quite accurate --- and not only for correct programs. I stuffed in rules so that errors are boldly flagged. For instance, even little things like using an undefined escape sequence in a character string or regex literal. (And it knows the exact set for all literals.) This works remarkably well; hardly any typos I make get by it.

Syntax highlighting definitions also help with formatting; they provide the editor with nesting cues for indentation.

Working without this stuff this day and age is completely silly.

Reply on news.ycombinator.com