HN Explorer

Ask HN: Why hasn't visual programming taken over?

4 points by earenndil ↗ HN
I should hope it's obvious I don't want everything to be written in scratch. But consider this: the base unit of code is the character. I use vim because it's the best at manipulating characters. Your IDE (visual studio, intellij, etc.) understands your code on the AST level, but when you edit with it, you're still editing on the character level. It still performs character-to-character transformations, even if it uses that knowledge. Your code is still saved as a plain text file.

And this has caused all sorts of problems. For instance, you can make a flat text file which doesn't map correctly onto AST; this is called a syntax error. There are disputes about how the text file should be formatted (tabs or spaces?). Parsing is slow and difficult. Sometimes you misalign something; that only occurs because tokens have no boundaries.

Now consider the alternative: code is stored as a binary AST. Your editor is an interface for interacting with that AST, your compiler deserialises that AST directly into memory. An entire class of problems is eliminated. Whether your editor understands your code on an AST level is no longer a question. Yet, at the same time, the barrier to entry for writing an intelligent editor is significantly lowered. Same for writing a compiler. You get a lot more choice in terms of how you want your code formatted. Want your python code with braces, or your c code without? Done. The language itself doesn't even have braces or colons anymore. Any tool that parses code runs a lot faster. And we don't even need a new language! All we need do is define an AST format for a given pre-existing language.

I'll readily admit, my title was a bit clickbaity. There is some work on such editors. And the answer to my question is trivial: inertia. But the time has come to overcome that inertia, for the sake of all the wasted electricity and lost productivity. So here's what my post title should have been: 'Ask HN: will you help me write tomorrow's IDE?'

8 comments

[ 3.1 ms ] story [ 30.9 ms ] thread
clintonb
What problem are you trying to solve? You spend a lot of time talking about code formatting. The more mature teams I’ve worked with have settled on a format and use linters to identify deviations. From my perspective, that is a non-issue.

I can type characters much faster than I can drag a mouse, so I’m not seeing any increase in productivity. In fact, the coding part of my job is perhaps the most streamlined. It’s the design, planning, and people ops that consume the most brainpower.

earenndil
> You spend a lot of time talking about code formatting. The more mature teams I’ve worked with have settled on a format and use linters to identify deviations. From my perspective, that is a non-issue.

Formatting is not a major part of the result, it is just a nice side effect; I didn't mean to give it so much attention. I will not say, however, that formatting is a non-issue. It isn't an important issue, but it is one that a disappointing number of man-hours have been spent thinking about. Just look at all the comments and controversy on this ticket about zig not supporting tabs: https://github.com/ziglang/zig/issues/544. Consider how much time has been spent making auto-formatters, and making them preserve things like comment alignment. There are 'less mature teams'; what will you do for them?

> I can type characters much faster than I can drag a mouse, so I’m not seeing any increase in productivity.

Like I said, I don't want to rewrite everything in scratch. I have no intention for the future to be anything but keyboard-driven; an editor which is aware of tokens and syntax trees will be better able to facilitate editing, no matter what your inputs. Consider fructure[1], which is not dissimilar to what I propose. I don't think it uses the mouse at all.

1: https://github.com/disconcision/fructure

pjmlp
Visual programming has certainly taken off on digital arts, electronic engineering and introduction to programming fields.
earenndil
Sure. But it hasn't taken as the dominant way of editing c++, python, or javascript.
fiedzia
> you can make a flat text file which doesn't map correctly onto AST;

if you operate on AST, you still can create invalid AST, so not much of a change there.

> There are disputes about how the text file should be formatted

Solved by autoformatters.

> Parsing is slow and difficult

that's the only drawback so far

> Your editor is an interface for interacting with that AST

So now you can't use your text editor, and must use something that understand specific AST (and even specific version of that AST). Any change to that AST will require all the tools to be updated, while currently any text editor or processor can be used to edit any programming language in any version. So you just created massive problem with the tooling. Your grep, documentation generator, sed and countless other text tools just stopped working.

gus_massa
Have you tried it? It's nice for very small projects and demos, but when the program gets longer it's painful. Perhaps a new editor can fix it, but I doubt it is possible.

Also, the conversion of text to AST is not straightforward. What do you do with infix operators? In the AST you loose the hability to write nice math formulas. What about f'' strings in python? I'm 99% sure they are desugared, specially the new version with the = sign.

earenndil
I'm not talking about scratch or UE blueprints. The thing I'm talking about doesn't really exist yet; there is some research into it, but it's nowhere near mature enough to draw conclusions yet.

The AST would be designed for human consumption and it would include information like f-strings. Infix operators would not be lost in the first place.

ksaj
I've always thought someone should make a Lisp editor that is essentially visual like Scratch and AgentSheets/Cubes. The pages (or desktops or whatever you want to call them) and on-screen position and size can simply be held in ; comments using the familiar X windowing layout method.

That way, you can have different screen/page/workspace environments tailored to whatever it is you are working on at any given time.

The way Scratch lays out functions in graphical C-shaped objects makes it pretty much impossible to do incorrectly, and ensures your inputs are always correct. Except I'd make mind collapsible, since you don't always need to see the code itself, but the functions are always right where you want to see them.

I'd also incorporate ideas from Blender and Logic Audio's MIDI patching interface, which are sort of like dia on steroids.

It's something I've always wanted to do, but it is, at least currently, outside the perimeter of my available skill set, and I haven't bumped into a team that would be interested in creating it.