Hacker News Reader

Comment by arnsholt | Hacker News Reader

After programming in SmallTalk for a while, I'm starting to come round to a similar point of view. I haven't quite made the leap in my day-to-day work yet, but I really am considering it.

Another thing I'm considering to adopt from ST is dropping syntax highlighting. If research on highlighting for natural language can be transferred to code (I'm not entirely sure, but I suspect it might), highlighting might actually be harmful to comprehension. The only thing I'd keep is a slightly lighter colour for comments, as these don't have quite the same status as code. Ideally, I think I'd like to have them deemphasised by moving them off to the margin or something like that, but that requires rather more work than rendering them a lighter colour than the rest of the code.

View on HN

> If research on highlighting for natural language can be transferred to code (I'm not entirely sure, but I suspect it might), highlighting might actually be harmful to comprehension.

Interesting. Could you share some of that research and its conclusions?

I don't remember whose research it is (it's a bit removed from my field of expertise =), but the gist of it is that they tried to highlight different parts of speech in running text in different colours, and showed that it actually decreased reading speed and comprehension.

Of course, there are several possible error sources (unfamiliarity with the colouring scheme for example), and whether this can be transferred to reading code is an open question. But I still think it's important to keep the existence of this kind of research in mind when discussing this kind of question (and also the similar question of mouse-driven interfaces vs. keyboard shortcuts), as it easily devolves into strongly held opinions and arguments along the lines of "it stands to reason that $opinion-held-is-true"

On the other hand there is Color Forth, which replaces syntax with color. It produces extremely compact code.

To go further in this direction, check out Piet: https://en.wikipedia.org/wiki/Esoteric_programming_language#...

I've always considered those kinds of studies suspect. When I'm reading, human-language text, I spend most of the time going forward. Maybe I'll skip to an earlier part of the sentence if it turns out to be a garden-path parsing, or to a previous sentence to re-acquaint myself with context. Those are exceptional cases.

In code, I'm frequently tracing back and forth through a block, looking for specific information in different lines. I think that the coloration helps to provide "landmarks" for non-linear traversal of the code. I'd consider color-free code to be more similar to un-punctuated text, than I would consider colored text to be to colored code.

> Ideally, I think I'd like to have [comments] deemphasised by moving them off to the margin or something like that

This is one reason I'm a fan of Douglas Crockford's slightly unorthodox style of always beginning comments in column 0, rather than indenting them along with the code. This helps, to a small extent, in differentiating comments from code. Example: https://github.com/douglascrockford/JSLint/blob/master/jslin...

Oh, that's an interesting idea!

Ideally, I'd prefer to float them to the right margin (suggesting the Lisp style of line comments starting at column 78 or thereabouts, I guess), but this is an acceptable compromise. At first blush it seems to break the flow of the code a bit too much, but I'd probably get used to it reasonably quickly, especially in conjunction with grey comments and black text.

This resembles certain forms of literate programming, like Haskell's "Bird style"[1] or Literate Markdown:

[1]: https://wiki.haskell.org/Literate_programming [2]: https://ghc.haskell.org/trac/ghc/wiki/LiterateMarkdown

I've dabbled with it and enjoyed it, but I really feel like it needs editor support to feel truly fluent (i.e. being able to preview the formatted version on the fly, being able to collapse the text blocks, etc.).

Reading code isn't the same as normal book or news reading. You don't need to actually read the whole code. Most of the time we looking for a specific variable or function call. Syntax highlighting allows you to filter out everything that's the wrong color to find what you're looking for faster.

I've tried to look at code without highlighting and I can't read it because the color gives me additional context (metadata?) about the code.

I'm profoundly more productive when syntax highlighting is enabled. It's easier for my brain to focus on the details it needs at any given point, versus when it's all the same color

I'm sympatheic to Smalltalk's approach to highlighting, but as long as we're all editing text files that contain multiple classes / functions / methods / etc... colorizing a few tokens (like class/func/let) is still valuable.

Reply on news.ycombinator.com