I program without syntax highlighting(hakon.gylterud.net) |
I program without syntax highlighting(hakon.gylterud.net) |
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.
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
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.
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.
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.
Hopefully when I’m done, you can take a peek to see if can help with your dyslexia
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.
Different strokes, for different folks. I personally use Monokai where each token type has and ‘extreme’ colour (like full red, full green, full yellow, etc.) — I absolutely love it and, for me, makes code much easier to parse
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.
I get that he sees words and numbers colored but the rest of us like the quick visual context it gives when trying to quickly find things in large files. So I'm with you, :syntax on
This is a post about preferences. Why do you think your preferences are "more valid" than theirs?
for (i=0;i<3;++i) {
/* Do initialisation here!
niftyConfig = 1;
funkyValue = 2;
}
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.
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.
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 can’t help but wonder how those same engineers are adapting to the current wave of AI-powered development tools like Claude Code and Cursor.
In that, I think there is a difference between those tools and AI. AI can write code fast, but can definitely also hurt your ability maintain a codebase if you aren't keeping it in check.
I don't think there's any level where synatax highlighting could make a codebase worse.
That was a long time ago - and he was still young. But not so long ago I asked some keyboard manufacturer (Ducky?!) to add more macro features for productivity - and I got the answer that it would be cheating to play back macros faster than normal writing speed - Recording macros on a keyboard and playing it back faster than recorded was impossible by design because they don't want to support cheaters.
Oh those coders... I wonder how much code on Github is invalid because of cheating...
[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.
I thought he used his own hacked-up micro Emacs thing, but maybe he dropped it.
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.
> Syntax is not the most challenging part of programming.
It seems like unless you’re learning the language it’s mainly a distraction.
I have synesthesia and so get syntax highlighting for free.
I like my highlighting to give me "synesthesia bootstrap speedup"; on the contrary it annoys me when it clashes.
It's an extreme case, but I presume as with most things there's a spectrum
I strongly suspect the older and more experienced a developer is, the more likely they are to code without syntax coloring, including large numbers who previously didn’t.
Language models made syntax highlighting extremely cheap to make.
… coding without syntax highlighting deprives you of signal!
Hand-crafted artisinal 1 and 0s is the best, most productive, way to code.
/S Obviously?
>If the code is neatly organised, the «grey mash» quickly crystalises into a beautiful little universe of logically connected parts; each standing by it self, on its own line or in its own scope, but referencing each other in clear and beautiful ways
Delusions packaged as deep insights.
Also, VS (codename Boston) was used as the de-facto internal development IDE for a few years before it we released it to the public. There were also arguments about shipping those types of features publicly.
Fortunately syntax highlighting isn’t part of the code, it’s just how it’s displayed. There comes a point where pasting images of code, to preserve syntax highlighting, into chats, email, and documentation it’s not only a waste of space, it becomes an ADA issue. Use whatever fonts and themes in your editor, but keep those to yourself.