Ranty challenge after a long day for anyone working on visual languages: before trying to support running programs, aim for a simpler domain like figures. Something with the controlled placement of SVG, the high abstraction of http://plantuml.com (which supports lots of different kinds of diagrams -- and the abyss of all possible combinations of them) and the WYSIWYG UI of MS Word or draw.io (which I find myself frequently fighting with). Why the heck doesn't this exist yet? How does every drawing tool manage to suck without bound?

Visual programming tools should be drawing tools first, and programming tools second.

@Kartik Agaram What were you trying to create with a visual tool that frustrated you so much? I'm curious of visual programming myself. I've had my share of frustration with draw.io, but have never come to be able to articulate the issues. What is your take on that?

Today it was a schema for a set of database tables. Pointing and clicking through a maze of toolbar icons all alike until I felt demented. Working with a template but repeatedly accidentally destroying it and knowing no way to create the layout it shows from scratch. Go to draw.io and start a new figure, from the standard

database_1

template under 'software'. You get a bunch of tables. How do you create one from scratch? The toolbar doesn't change from its usual settings. So you can helpfully add various flowchart icons to your database figure.

Ah. So it sounds like this particular issue is that the drawing tool isn't flexible enough to allow users to construct figures that make sense to them.

It has to walk the line between flexibility and automation. And as a WYSIWYG tool it has to do it perfectly. Very hard problem. It's a much more tractable problem as a textual language like LaTeX. The tool gets more slack in terms of latency, and that changes the game. A textual tool can be just internally consistent and that's good enough.

What do you see in "automation"? What is being automated?

In this context, automation = abstraction. If you want a pixel-level drawing tool, there are many decent solutions out there. (My favorite is Xfig as a front-end for SVG.) What we need is a pixel-level drawing tool along with some notion of a library of pre-drawn primitives. Packaged in a way that allows you to bump down to pixel-level manipulation anytime you want.

By "pixel-level" you mean something like raster graphics manipulation?

I was thinking vector rather than raster graphics. But we eventually see assemblages of pixels, and we want precise control over them. There are no semantics in this domain as I imagine it. Just pictures.

Ah ok. You were referring to drawing tools specifically.

Yeah, exactly.

Thanks for the find!

a lot of times documentation flows don’t get the same kind of engineering toolchain love as something like source code would.

I like what the author said here. It's more our obsession with text that prevents more prolific use of diagrams.