1. 18

  2. 19

    Syntax coloring isn’t useless, it is childish, like training wheels or school paste. It is great for a while, and then you might grow up.

    This seems… Overly dismissive? I’ve seen a few programmers talk about working without syntax highlighting, but I know for me, it’s a nice aid for navigating code. It gives my eyes and brain more structural hooks to hang things on, and makes skimming a lot easier, even when it’s all in gray-scale. (Skimming is one of the main ways I read code, looking for the relevant part of a file or function). I will admit that I’ve not been programming as long as Crockford, but I’ve also not been developing for an insignificant amount of time either.

    Plus, pervasive Navigate To Definition for the languages I use, or Vim’s # and * commands help me track down what context a variable comes from pretty easily in most cases.

    1. 5

      Yeah, that part irked me as well.

      I also see his point: common uses of syntax highlighting tend to go overboard. Each piece of syntax we style differently attracts attention. Thus, in a language that leans on parenthesis, rainbow parenthesis are remarkably sane. In another language, coloring every set of parenthesis isn’t as useful.

      I just checked CLion and found a few things that I appreciate that use syntax highlighting:

      • strings as a different color, so I can tell when I miss one
      • macros as a different color
      • unused vars grayed out
      • keywords as a different color

      Not all of them are must have, but it’s a much shorter list than a lot of the popular syntax coloring schemes, which seem to revel in using a different color for each type of syntax it can find. Less really is more.

      1. 2

        Yes, there definitely is a balance in how many different things are syntax highlighted, and one can definitely go overboard. (Right now, I’m used to having types highlighted differently than variables, but it’s not a must).

      2. 5

        The main idea is not bad, but I agree it’s a weird and unnecessary flex. He sounds extremely out-of-touch.

        1. 7

          I thought for years that I needed syntax highlighting, until I gave going without a serious shot. I would never go back to angry fruit salad after a couple years working with it off. Colour can have some uses but syntax highlighting defaults are not the way for me.

          I think a lot of people are where I was: convinced they need the highlighting because it is what they have known.

          1. 6

            I can definitely imagine how you can do without, or even thrive in the absence of, syntax highlighting, and I should experiment with that some time. I’m calling him out of touch for insinuating that something that’s the default for probably 99.99% of programmers is a conscious decision favored by the immature code-illiterate newbs. Gratuitous, because one can simply remove those statements to no detriment to the point.

            1. 4

              I think the best approach is to come up with your own theme. For example, I’ve been using my own theme (the screenshots are a bit dated) for the last decade or so. Over the years I’ve gradually reduced the amount of colour, leaving colour for elements that I want to stand out. I did try a few greyscale/low-colour themes, but I found it made my eyes more tired than usual.

              1. 2

                +1 for making your own theme.

                It’s been a lot of work and even though I think mine is pretty rudimentary based some others I’ve seen, it’s been really nice.


          2. 4

            It’s something Russ Cox(?) has mentioned too. Maybe it comes from programming before it was widely available. Personally I don’t think it helps you navigate code, because syntax highlighting doesn’t particularly highlight the logic or program flow, it instead helps one navigate text, to form a mental model of where one might find code. But it’s nice to have, at least to stop the screen blurring into a mess if you stare too long, at most to identify where things are happening at a glance as you said.

            1. 1

              I suppose I don’t see the difference between navigating code, and navigating text? I know that code isn’t just text, but text (or some representation), is the representation of code one usually interacts with. Or rather, the distinction seems small enough as not to matter? In order to navigate code, you must first be able to navigate the text it is comprised of, no?

              1. 1

                My beef is that it generally highlights the obvious (keywords) and not so much the less obvious (confusingly similar symbol names, brace matching, assignment over equality, etc.). I would at minimum want comments and strings highlighted though.

                1. 1

                  I very much want an emacs color theme that does this, but haven’t managed to find one.

              2. 3

                The language being used here is certainly not how I would phrase it; It’s almost, ehm, childish :-) But ignoring the choice of language, I do think he has a decent point overall. The quote continues with “I no longer need help in separating operators from numbers. But assistance in finding the functions and their contexts and influences is valuable”

                In other words: I don’t think Crockford is against this kind of usage of syntax highlighting, just “trivial” syntax highlighting which doesn’t give the advantages you describe (and even proposes a novel way to do highlighting to get similar advantages).

                This matches my experience; some syntax highlighting I see wants to colour every little thing, which in my opinion is much less useful than colouring useful “anchor points” such as comment blocks, control statements (if, for, return, etc.), and function/class definitions. I also find it slightly useful to highlight strings as I often use that when scanning code as well.

                Highlighting stuff beyond that like operators, numbers, function names, function calls, highlighting function calls different from method calls, and whatnot: I don’t really see how that’s helpful, and find it even detracts from the ability to scan. It’s some matter of personal taste of course, but syntax highlighting is UX design and like all UX design there’s good designs and bad ones. An interesting and perhaps more striking example of this is this page on colour design in flight control systems.

                1. 1

                  How about syntax coloring the natural languages? So we give nouns, verbs, adjectives, and etc different colors. All the punctuation marks also get their distinctive color. I would call that childish.

                  Context coloring would be useful for natural languages. So we can immediately see which sentences expand the previous statements, and which sentences start a new argument. But has anybody ever done this? Some people do like to make a whole sentence bold. I guess that’s similar to the concept.

                  Both arguments seem to be stronger for natural languages than code. What about formal logic? Lambda calculus? Brainfuck?

                2. 7

                  Why not both? Code coloring should be assignable to overlays you can toggle and untoggle at will. I should be able to my “imported functions are red” overlay and add a “params used in the body of the function are blue” rule, and then swap that overlay with one that has “functions that return option types are red and all classes that are in this git branch (but not main) are yellow.”

                  1. 1

                    That sounds nice. If I was trying to one-up the author, I’d venture to say that if the editor has access to a parse tree, painting whole contexts in one color is one of the less imaginative things you could do with it. :-)

                  2. 5

                    This is an incredibly awful article, I don’t know where to start.

                    This allows us to instantly see how the nested functions close over the outer functions.

                    We already have something for this. It’s called indentation. Comprehending his example code was no easier than if it were completely unhighlighted. I’m curious if any other Lobsters did.

                    Syntax coloring isn’t useless, it is childish, like training wheels or school paste. It is great for a while, and then you might grow up.

                    Got it, Real Men ™ program in monochrome. I hear they also only program in Fortran, Lisp, and assembly, unlike all those other, childish languages.

                    I no longer need help in separating operators from numbers.

                    No one uses syntax highlighting to differentiate operators from numbers. The most common use cases by far is highlighting of string literals, comments, and keywords. These are all very valuable. Syntax highlighting is a way to quickly find the end of a comment or a long string literal that might otherwise take some conscious effort to find. And keywords are highlighted because it’s often very easy to mistake one with an identifier, due to the syntax of most languages.

                    But assistance in finding the functions and their contexts and influences is valuable.

                    Scope does not help you find “influence”. The “context” of code is understandable in the whole. No amount of syntax highlighting will help you understand why something is inside an “if” instead of its parent scope.

                    1. 2

                      Bizarre. I find turning off syntax coloring useful when I’m trying to learn new syntax (because it makes it harder to read).

                      I turn it back on when I want to get work done because it makes me faster.

                      1. 2

                        We already have something for this. It’s called indentation.

                        Look more closely at the green encoder references at the bottom. In a language with closures, it’s not a one-to-one correspondence between indentation and what he has proposed.

                      2. 3

                        This basically requires that the highlighter is also an interpreter (and, in this case, full trichromacy on the part of the reader).

                        1. 3

                          You could get away with italic/underline/bold/halftone.

                          I’m not colorblind but I do have terrible vision (completely blind in one eye, bad but correctable vision in the other). I tend to prefer monochromatic syntax highlighting that uses textual features like bold/dim/italic for that reason; it increases contrast.

                          1. 1

                            Yeah, I think I use the different brightness of highlighted keywords as landmarks, rather than specific colors themselves. Thinking about it, I’m not sure I’d find chunks of blue (or italic, or…) code particularly helpful, at least compared to a highlighted if at the top of an indented section.

                          2. 2

                            Surely you could use static analysis on the source text? I don’t get why you’d have to interpret code to understand which scope is where.

                            1. 3

                              I think his point is that syntax coloring requires much heavier machinery than a DFA.

                              Static analysis is a form of interpretation, after all. You have to understand the language itself, rather than stopping at lexemes.

                              1. 2

                                Ehhh… trivial syntax highlighting can be done with regex’s, kinda. I wish text editors would use proper parser for syntax highlighting though. Vim often gets confused with strings in some of the languages I work in (the worst case being embedded JavaScript in an HTML file, which is understandably difficult to parse with pure regular expressions).

                                Certain nested structures (e.g. string interpolation) are better represented with a more formal language grammar anyway. Besides, it’s a bit silly that our text editors often parse the same source file multiple times – first, done poorly with buggy, monstrous regular expressions, then again by language plugins so you have functionality like Jump to Definition. You might as well just combine the functionality together and parse it properly from the start.

                              2. 1

                                Oh yeah, sorry, I meant “interpret” in the vaguest sense, i.e. “understand the semantics”, as @mattgreenrocks confirmed. Static analysis programs and compilers are just interpreters in funny hats.

                            2. 2

                              Is there an implementation? I don’t see one.

                              1. 1

                                I like syntax-highlighting threads, so I’ll take this opportunity to refresh my colorscheme’s screenshot. Some notes:

                                • Light background. I used a dark one for 20 years ever since my days on DOS. Paradoxically, trying out dark mode on Mac OS got me to switch. I liked not having big transitions when I Alt-tabbed, but I couldn’t stick with dark mode on my browser. Thanks Mac OS for helping me realize that I didn’t actually want what I thought I wanted.

                                • No colors for keywords. The only exceptions are break, continue and return (and goto). I’ve been bitten by early-exit bugs in the past.

                                • Colors for literals, particularly string literals.

                                • Multiple colors for comments. In fact, in the machine code notation I’m designing I has 4 colors for comments. (That’s overkill for more high-level languages, though.)

                                • On-demand colors for variables. It’s important to me that these are a) explicitly requested per variable, b) persistent across restarts, and c) randomly selected. With those three properties I get help visualizing the dataflow of key variables and can let myself grow a mild case of synaesthesia where I grow to expect them to be colored a certain way. But I’m in control to ensure it doesn’t get too overwhelming, and that each variable packs a punch when it appears on screen.

                                (My previous syntax-highlighting comment.)

                                1. 1

                                  Why not have different types of highlighting that can be toggled at any time? There are many different tasks and contexts, so the strangest thing is to think that there is one true way to highlight. At one point you might be interested in function nesting, but at another you might want to focus on exception handling, or async functions, or exported vs non-exported functions, or unused code, or many other things. And traditional syntax highlighting is an aid to navigating code, so it’s definitely useful as one of the modes.