8 ms·

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

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.

TeMPOraL 9y ago
> 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?
- arnsholt 9y ago
  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"
  - keenerd 9y ago
    On the other hand there is Color Forth, which replaces syntax with color. It produces extremely compact code.
    - zevyoura 9y ago
      To go further in this direction, check out Piet: https://en.wikipedia.org/wiki/Esoteric_programming_language#Piet https://en.wikipedia.org/wiki/Esoteric_programming_language#...
  - khedoros1 9y ago
    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.
Osiris 9y ago
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.
- danek 9y ago
  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
oneeyedpigeon 9y ago
> 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/jslint.js#L133 https://github.com/douglascrockford/JSLint/blob/master/jslin...
- arnsholt 9y ago
  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.
- djur 9y ago
  This resembles certain forms of literate programming, like Haskell's "Bird style"[1] or Literate Markdown: [1]: https://wiki.haskell.org/Literate_programming https://wiki.haskell.org/Literate_programming [2]: https://ghc.haskell.org/trac/ghc/wiki/LiterateMarkdown 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.).
tl 9y ago
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.

TeMPOraL 9y ago

> 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?

arnsholt 9y ago
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"
- keenerd 9y ago
  On the other hand there is Color Forth, which replaces syntax with color. It produces extremely compact code.
  - zevyoura 9y ago
    To go further in this direction, check out Piet: https://en.wikipedia.org/wiki/Esoteric_programming_language#Piet https://en.wikipedia.org/wiki/Esoteric_programming_language#...
- khedoros1 9y ago
  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.

Osiris 9y ago

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.

danek 9y ago
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

oneeyedpigeon 9y ago

> 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/jslint.js#L133 https://github.com/douglascrockford/JSLint/blob/master/jslin...

arnsholt 9y ago
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.
djur 9y ago
This resembles certain forms of literate programming, like Haskell's "Bird style"[1] or Literate Markdown: [1]: https://wiki.haskell.org/Literate_programming https://wiki.haskell.org/Literate_programming [2]: https://ghc.haskell.org/trac/ghc/wiki/LiterateMarkdown 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.).

tl 9y ago

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.