This seems like a sort of programmer hipster/macho-ism, like writing on a typewriter. I first learned to code without syntax highlighting, wrote (and still sometimes write) code ideas with pen-and-paper, but syntax highlighting is just plain easier to read for me. Things like vim-clojure-highlight that add semantic information make it even more useful.
EDIT: I also think there’s something to be said for your environment making you happy to work in - if you enjoy having a nicely-coloured editor, I think you’ll be a more productive programmer with highlighting and vice-versa if you find the colours distracting.
It seems to me (being the author, so biased) a bit unfair of you to write off my experience this way, but take it as you will. I find it sincerely beneficial, and as for it being hipster / macho-ism – wouldn’t someone have to notice for those things to be applicable? Until this article (and nofrils) randomly caught someones eye yesterday, it had like 5 views and nofrils had like 3 stars on github.. for months.
When I started, I was actually fairly sure I would hate it – I was challenged by a friend to do it for a week and ended up liking it. 20 years of development with 0 of those days being without syntax highlighting prior to that. I had written my own schemes (yes, plural) for vim. Heck, the reason I initially was drawn to vim was due to syntax highlighting being relatively consistent between languages.
I even tried Emacs (with Evil) for a bit mostly for rainbow-identifiers.
It seems to me (being the author, so biased) a bit unfair of you to write off my experience this way, but take it as you will.
I apologize, I came off as overly dismissive, I don’t wish to discount your experience. I personally prefer syntax highlighting, but I am sure that different people will have different experiences with it.
I first learned to code without syntax highlighting, wrote (and still sometimes write) code ideas with pen-and-paper, but syntax highlighting is just plain easier to read for me.
Came here to say this. At least for me, the benefits of syntax highlighting vastly outweigh the cognitive overload it purportedly causes. Also, I’m not completely sold on the Stroop Effect theory about syntax highlighting.
Also, I would say it depends on your colorscheme. Some are definitely garish and hard to read, but schemes like solarized, gruvbox, and whatever GitHub uses seem to be easy to read.
I agree, but sometimes there is a thing like too much syntax highlighting though. At some point, adding an extra color for another type of element is just like adding noise.
“Hey look at me; my brain evolved sections which are capable of assigning meaning to color subconsciously, but I’m going to offload all the work they’re doing to my conscious mind because it makes me feel tough.”
Color is not the only subconscious mechanism for assigning meaning.
Syntax highlighting, in many editors, is just overblown.
Too many different things highlighted for no real reason. Colors chosen that don’t go together at all.
A few things are good with syntax highlighting, such as language keywords and string constants. The rest, I’m not so sure about.
What I’d do if I really wanted to turn off syntax highlighting is to only highlight string literals and comments, to separate code from non-code. Which is in the end what he did anyways.
Rob Pike (I think?) wrote a bit he thought how syntax highlighting traditionally only highlighted the obvious, rather than little things like the difference between = and ==.
I’m thinking that syntax highlighting would help more if it was context sensitive. As in, it understood the content of your code, sort of like another pivot of hungarian.
E.g., smart pointers are green, raw pointers are pink. Variables containing user input are red, sanitized input is purple. That sort of thing.
You could flip through different color views to see different semantics of your code. In this function, which of these things are const and non-const? Which of these things are declared on the stack, or on the heap?
I’m thinking that syntax highlighting would help more if it was context sensitive.
This just feels like needless masochism to me. I can’t even conceptualize a world in which syntax highlighting is not a straight up win on every count.
This just feels like needless dogmatism to me. I can’t even conceptualize a world in which questioning your assumptions and testing them is not a straight up win on every count. You can question the OP’s results and method, but dismissing an attempt to test this basic assumption as needless seems really silly, especially coming from a programmer. How much nonsense have we as a profession brought into the world by failing to question our assumptions as we work?
You make a good point. For me, being forced into an environment where I DON’T have syntax highlighting is exceptionally painful. I remember the bad old days with edlin and ed because your TERMCAP was perpetually screwed up and also emulation that ran on microcomputers was horribly bad back then.
It was not fun.
I definitely understand having that reaction if you associate “losing syntax highlighting” with “screwing up your TERMCAP and being relegated to using ed.” :) This is beginning to remind me a little bit of IDE-vs-text-editor discourse writ small - I’m not saying that either syntax highlighting/no syntax highlighting is unambiguously better, but it’s important to question your assumptions and find what works for you, and I thought the top comments on this article really undervalued that aspect of the OP.
Jumping into this from another viewpoint, but I started programming on calculators with monochrome screens, then using notepad to write lua, and then Notepad++, my first editor with syntax coloring. I think I can reasonably say that syntax coloring is a win for me.
However, I think this whole thing is turning into a Holy War like Vi(m) vs Emacs. Honestly, use what works for you, write clean code, and build great products. Worrying about whether or not you should use syntax highlighting is bikeshedding, IMO.
I can’t even conceptualize a world in which syntax highlighting is not a straight up win on every count.
I can. This is far more distracting than the non-highlighted version: http://evanhahn.github.io/English-text-highlighting/
I had missed that link, it is illustrative, thanks!
“Do not marvel at this; for an hour is coming, in which all who are in the tombs will hear His voice, and will come forth; those who did the good deeds to a resurrection of life, those who committed the evil deeds to a resurrection of judgment. "I can do nothing on My own initiative As I hear, I judge; and My judgment is just, because I do not seek My own will, but the will of Him who sent Me.” - John 5:28-30
This is not the first blog post about switching of syntax highlighting that I saw, but it shares a lot with those others. For one, most of them are more “experiments out of curiosity” than changes out of a desparate need. The times I use editors without syntax highlighting are enough so that I don’t feel like switching it off.
Nevertheless, it is very interesting that syntax highlighting is so widespread, that such a blog post describes something that is highly unusual. Programmers have hardly agreed on anything canonical about programming environments, yet syntax highlighting seems to be one of the things 99% (guessing) of programmers can agree on.
Thinking about it a bit further, even in monochromatic times, it seems that programmers used visual cues for Keywords and such things. For example, by the time I learned Pascal, it was already common to write begin and end and var and while. Yet a lot of books and older introductory material on the web still capitalized such keywords BEGIN, END, VAR, WHILE. While pascal is case insensitve, WriteLn was hardly capitalized. I.e. I think that “syntax highlighting” started as a manual endeavour that has only been automatized since the introduction of colourful screens.
What could the benefit of working without syntax highlighting be? Perhaps a change can be fruitful and beneficial. When writing my thesis, I changed fonts when I was halfway through. Of course the content did not change, but I was able to read the text, as if I had not read it 30 times before.
I’ve been switching between acme (no highlighting, proportional fonts) and vim (highlighting, fixed fonts) regularly for a little over a year now, and I really like syntax highlighting off, too. It would occasionally save me from an easy mistake (eg, “return” didn’t turn green) but I often found myself hunting for colors to understand code instead of reading it, which felt like the same thing for a long time.
I wonder if how distracting the highlighting is depends on what language you’re using. I mainly write Clojure, so the structure is more explicit, with the colours pretty much only indicating the type of elements (e.g. numbers are purple, strings are green, functions are yellow). Maybe if you’re writing in a more C-like language the highlighting is less useful or more distracting?
I think it is most distracting for those who switch languages often, I am in that camp (average working day touches 3-5).
When I spent time in Eclipse, I used proportional fonts and absolutely loved it. Now I’m back in vim and it’s the only thing I miss.
I also did like 6 months where I had no syntax highlighting, can’t say I regret it.
What it really taught me though is how hard to scan some languages' styleguides are. You’ve got no syntax highlighting so you really work off of the raw code to understand what’s going on, and some style preferences are seriously uncomfortable to read compared to others.
Any examples in what you found was unreadable without syntax highlighting?
Mostly code that other people write. Other people base it on what looks nice, while with no syntax highlighting my whole style was based around what’s easier to parse.
This is especially exemplified in the JS community where everybody has their own style it would seem. No but more like there are like 5 different well known styles.
Sorry for late answer, forgot to login to lobste.rs.
I have not been using syntax highlighting for the past year. It’s not bad at all. The only thing I would recommend is using bold text for language keywords.
next step: stop using tmux.
(read: have tmux pried from my cold, dead hands.)
That seems less like “stop using a terminal multiplexer” and more like “use my text editor to spawn terminals instead of a terminal multiplexer”. IME, this actually works quite well; I do something similar with lots of shell-mode buffers and the occasional M-x ansi-term buffer in Emacs.
I find this silly; while Neovim does in fact have a terminal buffer, I’ve never used it.
Then again I’m one of those UNIX philosophy diehards who uses seperate programs for different purposes.
I actually think that (neo)vim is to blame in that case (and adding a terminal buffer type to neovim just makes everything a whole lot more complex). At the time vim was written, I’m sure there weren’t many available multiplexers (except for maybe screen, which is limited when compared to tmux). However, at this point, I’m convinced that tmux should be handling screen layout (since it’s way better than vim at it), and vim should just communicate with pipes (like kakoune). When I’m not thinking about it, I’ll often jump between panes when I just want to jump to a different vim window. I know there are things out there for vim/tmux integration, but they’re all super hacky.
Sure, at first glace you’ll make less bad assumptions about the code, but you also won’t be able to make as many good assumptions about the code as quickly.
I tried working with minimal syntax highlighting at one point (i.e. only strings/comments are highlighting in gray and rainbow parentheses - otherwise lisp is impossible), and didn’t really notice a huge difference. I guess I spent less time goofing off with color schemes, but apart from that, I wrote and read code basically the same way I always do.
Me too, everything in the default color, comments in an alternative color and dark red parenthesis. It’s much nicer way to edit scheme code than any syntax coloring I have seen so far.
What the article and some of the other comments here propose is actually a case against gratuitously over-colored highlighting, not highlighting in principle. As the author of highlight.js I can live with that :-)
Looks like he’s working on an emacs version of No Frils as well.
I started writing code with syntax highlighting off to prepare to read code printed out (or even, gasp, written by hand). I’ve found it doesn’t significantly impact my productivity either way, but it makes other programmers really confused and even mad.
I can read books without syntax highlighting, and I don’t think it would really help if all the verbs were green.
having programmed with and without syntax highlighting, I can comfortably say: whatever works for you, man, but I like my highlighting.