38 comments

[ 4.6 ms ] story [ 105 ms ] thread
I always felt weird about the fact that Scratch et al exist, and that typing things manually exists, but you can't type code and get a visual result that is scratch-like

- - -

To clarify, I don't mean generating a visual version, but to instead highlight structure (e.g. background color for a for-loop and its indent), not keywords

The weirdest thing is that several languages have formatters and linters that constantly convert text into tokens and then back into text. Just do it one time and convert what text the user enters into a token then process that token like you say into a visual block that guides the developer better than plain text with completions.
Absolutely! UML gets a lot of discussion, but a more reflective model of a written program is something I long for. I love the feedback that I get from, say, writing a Tupfile and running `tup graph` to see an actual graph of all my recipes, complete with their commands, inputs, outputs, and interdependencies as understood by the build system. I haven't used Unity, but it looks like it has blender-like node-based programming that gives me the same feel, where each box ia just code but the connections between them are illustrated. Lastly, Emacs allows you to instrument function definitions with edebug, and stepping through the code or even just letting it run in a loop and observing the movement of the point-of-execution has given me a lot insight into packages that I've worked on. None of this is really "the thing", but each example gives me the same vibes, of showing how existing code or control flows are structured.
This is a kind of thing people built to realize they’re not that useful looking at the results (still think they can have value, it just feels too limited to be widely adopted)

Take SQL for instance: we already have tools that will take table definitions and built an UML tree from that. I used that kind of tools 3 times in my life, and threw away the result to draw something manually to really understand what was happening. The main issues were excessive visual complexity, noise from all the meaningless bindings, random component placement making is hard to mentally group components.

I’d expect these issues to be 100x worse with any code that expands beyond a single function, as the cyclomatic complexity would in average be a lot higher and we’d have a lot more noise from guard conditions and boilerplate.

Looking at it the other way works too: coding what we write everyday in ruby or typescript, but in Scratch, would be a crazy visual mess that would push anyone into depression.

The closest to this I have seen is something like Mathematica, where the frontend can map back and forth between visual widgets and code pretty seamlessly. I always wished they would actually take it a bit further, but some of the things you can do are cool.
I don’t know, in my opinion an advanced IDE is sort of that - I don’t think of IntelliJ’s text as notepad’s - it is more an AST in textual form as per the language’s grammar.

My human brain is very fast at parsing that to a tree based on visual cues, while the program does the same constantly - syntax highlighting is important exactly for this reason, if it is colorful, it parsed correctly, that’s the feedback between machine and human.

Even manipulations are AST-level, I expand the selection based on that, etc. It just has a very fast, “invisible” node-edit mode where you can just type a few characters to change the function node’s name.

> The results suggest that syntax highlighting squanders a feedback channel from the IDE to the programmer that can be used more effectively.

Say what? As in the color channel may be useful in program comprehension, but wasted on lexical syntax? ... And we can tell from studying novices?

More like: opportunity to study syntax coloring was squandered on novices that don't actually understand the programming language.

Do other industries do this? In construction, do they test the effectiveness of a laser level by studying apprentices?

As a decidedly non-novice programmer, one thing I do when mapping out unfamiliar code architectures, which I haven't seen anyone else doing, is to generate large-scale code maps by "inlining" function call bodies into a large Google Doc, creating a deeply nested tree where indentation maps to control flow and stack depth, and vertical position maps to execution order (excluding loops). Then I often trace data flow for important variables, by giving the variable one foreground or background color, then giving all future usages of the same value (or pointers to it) the same color. Unfortunately preparing this type of document by hand is quite time-consuming. https://marketplace.visualstudio.com/items?itemName=wcrichto... seems to be a preliminary attempt at tracing data flow within a function, but doesn't seem to currently handle cross-function data flow (or generate an inlined tree suitable for visualizing caller-callee and sibling-call control flow).
What you're describing is generally known as interprocedural dataflow analysis. (Interprocedural because it handles dataflow across function calls.)

You can look into building a tool that can extract all or at least part of that dataflow graph for you by analyzing the AST. There are different approaches to this, some being more imperative (write a program to implement a chaotic iteration algorithm which builds the graph) and some being more declarative (extract facts about the code and feed them to a Datalog engine alongside a DL program describing the relations required to build the graph, or utilize something like CodeQL which already has the functionality available.)

Sourcetrail can give you similar (plus interactive!) visualizations automatically.
I wouldn't expect it to help much, if you don't have the vocabulary and a feel for how the code should look, syntax highlighting only points out similar things, which you can't comprehend anyways. Imagine trying to read something in a foreign language you're just starting to study, and someone went and highlighted all the verbs in one color and nouns in another, how useful would that be?
Good example. I sometimes teach programming to grad students who have no previous experience. When they first encounter syntax highlighting, they are impressed with how pretty it makes things look. However, it becomes apparent that it's more of a distraction than anything else, so I encourage them to leave highlighting turned off. Oh, except for matching bracket highlighting. That is genuinely helpful.
> and someone went and highlighted all the verbs in one color and nouns in another, how useful would that be?

Uhh, as someone who likes learning languages, this is immensely helpful.

One of my favourite Mandarin graded readers actually highlights personal pronouns in the text, (because names are just Chinese words) so we can read the story without getting caught up in "the car climbed the tree? Wtf? Oh no it's 'the guy named car' has climbed the tree"

That being said I agree that this is a digression, I think syntax highlighting will only help newbies marginally. There's a lot more that goes with understanding code

(comment deleted)
The results depend greatly on the type of syntax highlighting. Based on the snippets of the article I have access to, it seems they used very simple keyword highlighting and not any sort of data type or scope highlighting. It also doesn't mention in the abstract the task completion time.
I've never thought of syntax highlighting as helping me understand a program. Useful when I'm scanning code, though.
I’ve wondered if it would be useful to have formatting/highlighting be part of the language rather than something determined after the fact, for example italicized vars could be immutable, bold for shared, have literal “function colors” to indicate asynchronous or functions callable from non-main threads, stuff like that.

I haven’t really thought it through, but maybe the idea sparks somebody’s imagination out there.

We have enough conflict about the best case of tokens. I think any attempt to prescribe the colour of tokens would lead to all out war.
it helps for things like when you aren't sure whether 'True' is supposed to be capitalized or not, or whether 'elif' is a thing, but that's more 'language novice' than 'programming novice'
As a dyslexic person, syntax highlighting is amazing. I don’t care that the highlights are 100% correct or even useful for understanding what the code does. What I care about is that it breaks up the characters with something other than more characters. It helps keep my eyes looking at the “important” places in the code, or close to it. The shape of the code is important and highlighted code just “looks” a bit more correct.

Keep in mind, I’m no novice. So, my opinion is absolutely unrelated to the article… so it is on HN.

I’m not a novice and I don’t know what the colors mean either. I’m not dyslexic at all, but I feel the same as you. Code doesn’t look right, and the changes in color helps with readability.

It’s also a crude spell checker. “Hmm, the word didn’t change color so it’s probably not `elseif` … let me try `elif`. Yep, that changed color!” Kind of thing.

The other two major pain points where color coding really makes it obvious what’s going on, is when a string is left unclosed and everything turns into “the wrong” color and matching of parentheses.

Agreed - it's hard to put your finger on it, but _something_ makes the code much easier to parse mentally at a glance.
Does beautiful typography helps readers understand what they read better ? Is turning the lights on in the toilets really useful?
I am a bit different because I'm not a novice, but I use a lot of languages (I'm an independant consultant) and syntax higlighting is very important for me to switch from one language to another, or even jump into a new one.

My ideal situation is to have a language that Jetbrains tools understand, because I also learn things by just having the IDE extracting a variable or a function, I can understand some weird variable or type things by the way they typed the extraction.

For me one of the most valuable highlighting that an IDE does is not keyword highlighting, but rather color matching braces and parentheses.

Looking quickly at an expression or block and visually seeing where the matching braces/parentheses are is a huge time saver for me.

The only really useful highlighting I've found, really essential, is distinguishing comments from code. In on of my luddite moments I switched off all highlighting (because I am hardcore) and spent an hour debugging a block of commented-out code. Just didn't get why my changes weren't working. Stupid compiler.
When I was a newbie the value of syntax highlighting was catching syntax mistakes more quickly because the colors didn't change the way I expected.
It helps everyone and always. Don't believe me? Go program with it completely turned off for a month.

If you can suffer that long without switching back prematurely, maybe you're built different, and that's good for you, but noone I know could last that long.

Of course it does.

Believe me. I have programmed by writing code in plain text editors (vi / notepad) and compiling them on the command line and using a line editor to fix issues. I have also used IDEs and have come to appreciate the productivity gain afforded by syntax highlighting.

I like VisualStudio / VSCode but one recent issue I have had is with their parentheses/brackets/braces coloring. It doesn't add a lot of value as I am used to matching parantheses/brackets/braces using the hotkey. I find it annoying and distracting enough, but haven't bothered to research if that option can be turned off in the IDE.

Syntax highlighting is very helpful if you are a polyglot programmer.

> I like VisualStudio / VSCode but one recent issue I have had is with their parentheses/brackets/braces coloring. It doesn't add a lot of value as I am used to matching parantheses/brackets/braces using the hotkey. I find it annoying and distracting enough, but haven't bothered to research if that option can be turned off in the IDE.

Look into the setting '"editor.bracketPairColorization.enabled": true'.

Thank you! That worked.
Although I use syntax highlighting, I realise it's a habit I use without much thought. A counterpoint: most programming books are printed in black-and-white, and program listings (even with longer program listings) are perfectly readable in black-and-white.
It would take longer to find a missing " without syntax highlighting.
I've stopped using syntax highlighting, I just use bold for strings and italics for comments. I think other than for string/comment termination, the effects are placebo.