Full Metal Jacket: A visual dataflow language (2016)

> Even then, once a "program" gets complex it can get tangled fast.

In my experience with both visual and textual languages, the same happens in textual languages too, except we’re trained to use software engineering principles to attempt to manage the complexity (to varying levels of success). In my (somewhat limited) experience with visual languages, if you apply those same principles (especially some of the OO ones like encapsulation) and factor things into their own functions/nodes, it’s manageable too. Whether better or worse than textual probably depends on the use case and persons comfort level with either type of language and in practice most visual code I’ve seen was not written by a programmer and therefore the author did not know the software engineering principles that would have helped keep their code manageable.

> A node with 3000 edges starts to look messy. There are some things you can do to fix it but then you just kind of wish to use a simple script.

A text-based function with 3000 lines starts to look messy, too. That's purely a function of size, not building materials.

The analogous solution to "a simple script" is "a simple graph", i.e., abstraction.

There's one thing here I strongly agree with:

> There is no point developing new programming languages unless they're radically different from existing languages.

95% of the time, any language from the past few decades would work fine for what I'm doing, and I run into far more problems from languages changing than from languages lacking features. (Python 3 is the poster child for this right now, but I don't think it's even the worst offender.) One of my favorite languages is Common Lisp, and that hasn't changed since the 1980's.

There's also something here I strongly disagree with:

> Programs are composed almost entirely with the mouse rather than keyboard, and type inference and other checks take place while you edit your program.

If there's one thing that's true of all programmers today, on any platform, it's that they love their keyboards. You'll never get anywhere trying to get them to edit a program with just their mouse. Graphical programming languages are cool, but they need to incorporate keyboard editing. Like any IDE, you should be able to work with a mouse, but not required to. Put "graphical representation" and "mouse-only editing" in the same boat and the latter will sink the former.

I've known a couple programmers who hooked up foot pedals to their editors. I know nobody who's ever written programs with just a mouse. So based on my experience, you're going to have a tougher time selling anyone on this than if you'd made a programming language which required you to use your feet.

> The analogous solution to "a simple script" is "a simple graph", i.e., abstraction.

Right and abstraction is exactly what doesn't work well with visual languages.

With a script you can do a for loop from 1 to 3000. With 3000 components connected to one node in a visual language there is not obvious facility to handle it. You can think of group functions in components/namespaces/folder maybe. Or say generate implicit connections where they are not really drawn on the screen.

Excel succeeds at its job so thoroughly that I think people fail to realize (or cope with the realization) that spreadsheets are probably the most successful democratized programming environment we have. It may not have been intentional, but the 2D grid representation for data interlaced with an acyclic dependency graph is by far superior to any alternative representation, visual or otherwise, I can think of for either of those concepts.

Users don't even think about graphs or data, often they don't even understand those terms. Due to this IMHO spreadsheets are pretty much peak computer science