I personally find syntax highlighting unhelpful and very distracting, so I always turn it off. Sometimes it feels that I'm the only one. I'm pleased to read that I'm not.
I think Torvalds also goes on that list as another ACME user. He mentioned as much in the extended video interview he did with Microsoft recently.
For myself, I've had to spend a lot of time without colorful syntax recently as I was working on building my own IDE and my own syntaxes and even my own system of syntax highlighting. It would have been a distraction to be constantly fighting with someone else's system of syntax highlighting while building my own! But also even having learned that I can live without it I'm hardly ready to say that I never want it back. I just want it back better. I want dynamic, contextual highlighting and I want interactive access to the underlying tree model. I want it to feel really easy to tinker with too.
On my personal devices, I turned off syntax highlighting a few years ago to see how hard it would be to live without, but I ended up liking it and I have not turned it back on since. I am mostly working on small (<10k LOC) projects, or single-file programs (e.g. Advent of Code).
However, at work I am working on a much larger code base, and the extra help given by syntax highlighting (for example, having a quick visual feedback on whether a method exists or not) is valuable to me.
I think this also depends on the language used: at home I mostly program in C, but if I were doing more e.g. C++, I would probably enjoy some syntax highlighting.
Most syntax highlighting adds too many color variations.
In light modes, I find that variations gray and bolding certain symbols, variable names, function names in definitions and method calls to be enough.
Just enough hint so the brain can skim for the matching information. My editor highlights the opening and closing brackets of my current block,but indent level indicators are usually enough for me to visually validate.
Dark modes make contrast more difficult to discern though.
More generally the tools used to write the code show through in the code itself. In the way code is distributed across files, in the length and style of names, in the organization of modules. Using an editor without syntax highlighting like Acme, and also because it's Acme will encourage a different style of organizing a project and the code within a file.
> Supporting all languages equally future-proves the editor, because who knows which language we will use in ten years?
I remember which editors I used in 1990: emacs for most of my code and vi (vim now) for light editing mostly on remote machines. They are the same editors I'm using today. I went through some IDEs (Eclipse, NetBeans) because Java would have been nearly impossible otherwise but I never left those two editors for everything else.
They did not have syntax coloring in the 90s, they do now. It's not life changing but proper syntax coloring can make me spot an undefined variable or an unterminated string. I'm working only with interpreted and dynamic typed languages now so that's almost all it can be done without a compiler that runs in the background and checks the code for errors.
I don't use anymore any of the languages I programmed with 35 years ago.
> In Acme I double click on the outmost marker [...]
I'll represent the insufferable Emacs/Vim pricks by saying: Once I read you're using a mouse during development, my willingness to entertain your contrarian dx ideas dropped to near 0.
> The first thing one thinks when going from highlighted to unhighlighted code might be «This code is just a grey mash of symbols». Though, this sensation quickly fades as one gets engaged in the code. This “getting in to the groove”-part of the programming session is remarkably short, and afterwards code is more readable than English.
I mean, the fact that many people seek out and use highlighted code underlines that many people don't experience what you experience.
I remember back in the day programming PHP in notepad, unhighlighted. Finding Sublime Text 2 with highlighting was a revelation.
I think language matters quite a bit when it comes to how useful this is.
For simpler syntaxes like C or Java, I think the highlighting adds little. But as a language allows for more complex things like monkey patching or helper methods and the like, a little bit of color is really helpful. Knowing immediately that a method is built into the SDK or that it's some monkey patch that's been added gives me better understanding on what the code is doing.
That said, "go to definition" and "autocomplete" are the most important tools to me when it comes to coding.
As a dyslexic programmer, I often think about how I would never be able to do the job I do without syntax highlighting.
I don’t really know why it works so well for me, but I think it helps me skim and pattern match syntax much more easily without spending too much time reading every single word, which is exhausting for me.
Types and autocompletion in an IDE also help me massively reduce issues with spelling and ultimately free up my brain to think about the logic rather than stressing out about every single thing I type.
Really cool that some people don’t need it, but for me, I am grateful to those who have spent the time on great themes. Solarized Dark is a favourite of mine.
For about two and a half years I worked on a Smalltalk system, written in a quite old Smalltalk, which gave me two idiosyncrasies editor-wise: I no longer care very much about syntax highlighting (though I don't really bother to turn it off), and I now prefer to use proportional fonts for my programming. The only syntax highlighting I missed in the Smalltalk was a fading out of comments (which would in fact have prevented a stupid issue similar to the comment thing shown in the OP).
Syntax highlighting gains, regardless of color scheme, are not negligible. There are grayscale color schemes, for example, that remove the violent nature of some color themes.
I eat all my food without knife and fork. I find I am able to see the beauty in a pork chop when I cut it with a spoon and am able to appreciate its qualities better. Too tough and the cutting fails. I know then to rid myself of an ugly thing and buy another. Just right and I can scoop up a piece as soon as I get it to the right shape.
I remember when syntax highlighting was introduced in Borland's Turbo Pascal editor (on DOS). It was a very major usability improvement and put TP's IDE at the forefront of getting things done. Fond memories :)
I program without syntax highlighting. Comes from a combination of learning shell scripts within vi (not vim) and the bloatedness of syntax highlighting and autocomplete nonsense. Coding without it all is a nice way to ensure that everything can be encapsulated within your brain. Leads to different abstractions and such. It's fun and I highly recommend it.
Also, the comments in here are really strangely negative. Let people have their preferences, weirdos.
Also also: so much of syntax highlighting and such is designed by people without color blindness. So a lot of syntax highlighting just doesn't work for me. It's wild to me that color blind people still have to be vocal about it.
38 comments
[ 3.2 ms ] story [ 54.1 ms ] thread[1] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...
For myself, I've had to spend a lot of time without colorful syntax recently as I was working on building my own IDE and my own syntaxes and even my own system of syntax highlighting. It would have been a distraction to be constantly fighting with someone else's system of syntax highlighting while building my own! But also even having learned that I can live without it I'm hardly ready to say that I never want it back. I just want it back better. I want dynamic, contextual highlighting and I want interactive access to the underlying tree model. I want it to feel really easy to tinker with too.
However, at work I am working on a much larger code base, and the extra help given by syntax highlighting (for example, having a quick visual feedback on whether a method exists or not) is valuable to me.
I think this also depends on the language used: at home I mostly program in C, but if I were doing more e.g. C++, I would probably enjoy some syntax highlighting.
In light modes, I find that variations gray and bolding certain symbols, variable names, function names in definitions and method calls to be enough.
Just enough hint so the brain can skim for the matching information. My editor highlights the opening and closing brackets of my current block,but indent level indicators are usually enough for me to visually validate.
Dark modes make contrast more difficult to discern though.
I remember which editors I used in 1990: emacs for most of my code and vi (vim now) for light editing mostly on remote machines. They are the same editors I'm using today. I went through some IDEs (Eclipse, NetBeans) because Java would have been nearly impossible otherwise but I never left those two editors for everything else.
They did not have syntax coloring in the 90s, they do now. It's not life changing but proper syntax coloring can make me spot an undefined variable or an unterminated string. I'm working only with interpreted and dynamic typed languages now so that's almost all it can be done without a compiler that runs in the background and checks the code for errors.
I don't use anymore any of the languages I programmed with 35 years ago.
I'll represent the insufferable Emacs/Vim pricks by saying: Once I read you're using a mouse during development, my willingness to entertain your contrarian dx ideas dropped to near 0.
> Syntax is not the most challenging part of programming.
It seems like unless you’re learning the language it’s mainly a distraction.
I mean, the fact that many people seek out and use highlighted code underlines that many people don't experience what you experience.
I remember back in the day programming PHP in notepad, unhighlighted. Finding Sublime Text 2 with highlighting was a revelation.
For simpler syntaxes like C or Java, I think the highlighting adds little. But as a language allows for more complex things like monkey patching or helper methods and the like, a little bit of color is really helpful. Knowing immediately that a method is built into the SDK or that it's some monkey patch that's been added gives me better understanding on what the code is doing.
That said, "go to definition" and "autocomplete" are the most important tools to me when it comes to coding.
I don’t really know why it works so well for me, but I think it helps me skim and pattern match syntax much more easily without spending too much time reading every single word, which is exhausting for me.
Types and autocompletion in an IDE also help me massively reduce issues with spelling and ultimately free up my brain to think about the logic rather than stressing out about every single thing I type.
Really cool that some people don’t need it, but for me, I am grateful to those who have spent the time on great themes. Solarized Dark is a favourite of mine.
Language models made syntax highlighting extremely cheap to make.
I'm not convinced by the arguments of the article:
- actively clicking on matching parentheses has the benefit of selecting that part
- being more sensitive to the "beauty" of the code
I think syntax highlighting doesn't get in the way of these two points.
The only valid point:
- No syntax highlighting automatically supports all languages
True I guess. In the sense that no shoes support all feet.
modern editor features are very loud, and you don't notice it until you turn it off
that being said, this is not a good strategy for work editors
It may be just slightly more difficult, but then it's death by a thousand paper cuts if I'm reading code for 6-12 hours a day.
Also, the comments in here are really strangely negative. Let people have their preferences, weirdos.
Also also: so much of syntax highlighting and such is designed by people without color blindness. So a lot of syntax highlighting just doesn't work for me. It's wild to me that color blind people still have to be vocal about it.