Comment by rahen | Hacker News Reader

Comment by rahen | Hacker News Reader

This reminds me of how Rob Pike mentioned his dislike for syntax coloring as extra cognitive load, which seems odd in regards to current IDEs filled with information and stimuli.

With LLMs now directly interfaced to IDEs, it is likely that any obstacle will trigger a need for immediate AI powered dopamine reward. I wonder how programmers brains are going to rewire in this regard, even for those not subject to ADHD, but I suspect their sense of focus will worsen even more.

In the coming years, I wouldn't be surprised if writing high level code will slowly turn from mainstream to an edge art requiring focus and commitment, like assembly programming has already become. The casual developer will probably be just giving directives to an AI code bot and be incredulous when told how people used to write code themselves, pondering for hours on a bug in a bare boring terminal. A possibility is that what is perceived ADHD today might become the norm with future humans.

IMO syntax coloring lessens the cognitive load. What is "high level code". You are telling a machine what to do and to do it as fast as possible. Can you still make money telling a machine what to do but not as fast, depends but most likely. We code to ultimately make money in one form or another. Whether you keep that money or put it towards altruistic causes is independent of the shared commonality.

We should organise a study of our own: does syntax highlighting help or hinder and does the answer change based on your level of ADHD traits.

Could be quite interesting!

I have been diagnosed with ADHD and got an especially bad score for working memory.

I find myself tired out really quickly by a lack of syntax highlighting.

With syntax highlighting, I feel like I am not really reading the code anymore, but instead just registering the patterns and parsing the color tokens.

I think the most important aspect for me, is that I don't spend time reading where a token starts and ends. Ex.: If I wanna check the function name, I just have to read the only yellow thing in around this area.

I can register the tokens on a whole page in seconds, if the code isn't too dense. I just tried the same with syntax highlighting disabled and would say that I took about twice as long to parse the entire page. (I used a different, but similar file from a microcontroller HAL)

It's not adhd specific but https://arxiv.org/abs/2008.06030

After reading this I implemented a code theme based primarily around typographic variation like weight rather than color. It uses only two colors (black and deep purple) in two weights and one italic each. I have pretty severe adhd and it's hard to judge but after using it for a few months I think this is better for me. Previously I had been using solarized light for nearly a decade for probably similar reasons.

Nano emacs was created by the author of that paper and its default themes are based on it, if you want to try it without committing to hand-rolling a theme. Personally I found that one too "light" (typographically, not color) but I also have relatively poor vision and like a large and heavy font.

https://github.com/rougier/nano-emacs

I also immediately thought of Nano Emacs when I saw this article.

There is a short talk (6min) from EmacsConf 2021 where the creator of Nano Emacs talks about his reasons for designing a simpler interface, I found it really interesting:

https://emacsconf.org/2021/talks/design/

Yeah it was kind of a mind blower to me. I'm not in a big hurry to settle an opinion but I have a feeling these are ideas that I'll be exploring and influenced by for the rest of my career.

Note: there is an effect that less eligible font makes for deeper understanding (it makes the text harder to read thus your conscious has the time to process before your fast intuitive system I jumps to conclusions).

While skimming code (i.e., most of the time), syntax highlighting is useful. But it may be also useful to turn it off occasionally, to read some parts more thoroughly.

I have to agree. Syntax highlighting lets me recognise patterns in code without having to read it, and I actively avoid reading details I don't need.

(To me that is also what annoy me about IDE's - I want to focus on the shape of the code, not other stuff. When I focus on code, I want that code to be all that exists in my mind at that time; but I suspect whether or not you like IDE's is orthogonal to how you like your code presented)

But I also feel like there is an interesting range within developers from those of us who pattern match skim and "zoom" in on details to those developers who read code in detail, and I'm not sure those of us on different sides of that spectrum see perceptual load the same way.

On one end you find people like me who are purist about syntax and presentation because we're extremely conscious about avoiding having to read everything. E.g. I remember code by overall visual shape, and I can hold a lot of that in my head at once, but I don't remember what it says. I know where to find things rapidly, but not the details. I never try to remember the details.

On the other extreme you find people with like their code to look like K or J "line noise" or mathematical notation because it's short and compact which helps when they're deciphering the code symbol by symbol.

To me, the latter is the height of perceptual load, because I can't just look at it and have a rough idea what it might do, but I understand that some instead see it as stripping away extraneous details.

Interesting that you mention shapes, because for me that extends to keywords and stuff, e.g I don't care if def or class is highlighted, the shape of the code and the tokens tell me that, so it being coloured is redundant and thus useless cognitive load most of the time.

The main use I have of syntax highlighting is instead making sure the computer and I agree on these tokens being what I expect them to be; it's a form of live parsing error control, a direct feedback loop, not a way for me to parse code.

My ideal colour scheme is none at all, save for subduing comments (and being able to toggle that, subduing code instead) and colouring things in/around errors when a mismatch is detected (typically, unbalanced delimiters)

Syntax highlight never bothered me, and could even be helpful. But I can see where Pike is coming from.

What drives me nuts is autocomplete, because it pops things into my vision automagically while I'm trying to focus on the code, and even effects a mode change (some keys do different things when autocomplete is active).

Almost if not as bad, is when I'm working on someone else's code, and they misspelled a word when defining the class/method/function/variable, and now that misspelling is everywhere in the code because every other time they used the identifier they typed the first four characters max and then mashed TAB to autocomplete it!

> What drives me nuts is autocomplete, because it pops things into my vision automagically while I'm trying to focus on the code, and even effects a mode change (some keys do different things when autocomplete is active).

Totally agree! I disable "press Enter to accept suggestion" in JetBrains IDEs for this reason.

The existence of colored syntax is too broad for a conclusion here. It's the specific highlights/colors/contrast ratios/etc. that determine whether a particular theme is working for or against you individually. Still haven't found my "perfect" scheme, but I bounce around between a small handful based on my mood at the time--sometimes the less-loud ones remove unwanted stimuli, but other times I need the louder ones in order to see/focus on the code.

I prefer colored all the way, specially when "boilerplate" words become less vibrant, like 'def, fun, function, begin, end'.

Pure white/black words are really painful because it causes paralysis when trying to re-read a different page or file from the current one.

I simply get stuck trying to decide what to read first, because everything looks the very same, specially outside the peak minutes of the medication.

About Copilot, for instance I found really easy to give more instructions or context, or restart with new instructions whenever it spills bullshit code, even on programming languages that are unusual for me.

The problem is when to really give up because I still believe that I can convince the bot to spill what I really need. If I'm not familiar to the problem, even knowing that the bot is spilling bullshit, I feel a analysis paralysis deciding if I will handle manually, step by step, like the "old days", or giving more context to the bot.

So becoming familiar to certain classes of problems is something helpful, instead of specific implementations in certain languages.

No, IDEs do not give you ADHD. ADHD has a clinical definition and a physiological cause in a region of the brain.

Reply on news.ycombinator.com