If you want to check out a visual language in development that’s solved all 13 of those problems, check out Enso (previously known as Luna), whose niche is general purpose data processing and visualization.
IMO what sets it apart from other visual languages is that you edit the visual and text representations of a program at the same time, and its text representation is editable-Haskell-like rather than generated-config-file-like. Haven’t seen anything like it.
And as a core differentiating aspect, Luna code has dual representation, where a purely textal form of the code vs. the graph view can be converted both ways with absolutely no loss of logic (the storage format is actually textual + (x,y) position markers). Which can be seen as an important “escape hatch” should one consider visual programming a “leaky abstraction”, letting one use all your trusted text-processing tools (most notably, diff & vanilla git) for working with their code.
I spent a few years using Max/MSP/Jitter to create audio/video performances for clubs and raves right around the same time I was first learning PHP4 for work. I would never have used Max’s visual flow-based programming for “code-like” tasks but it was a brilliant way to connect data pipelines in a reactive, live control flow and hook them up to media I/O like MIDI and cameras. Visual programming has its place when inputs and outputs are well-defined and transformations on them don’t require recursion, instantiation, or deep layers of abstraction.
As far as I can tell, the two by-far most successful visual “programming” examples are LabView and shader node editors.
LabView has addressed nearly all of the issues raised in the article, and yet, in my opinion, it’s still sub-par as a programming language. I think the primary reason it has any market share at all is because National Instruments payed the marketing cost to get university engineering departments to use LabView in their undergrad labs, which meant instrument makers other than NI had to provide drivers for LabView, giving them a Microsoft-style pseudo-monopoly.
As for shader node editors, those are a perfect example of a dedicated graphical tool being extremely useful and powerful. They don’t try to be general purpose programming languages, and that’s why they excel at what they do.
Nice reference and concise summary of it!
I also find that some of these are true not just for visual languages, but also visual programming environments.
Reliability and the ability to handle large data sets is one reason I stick to the terminal, over IDEs and stuff like Jupyter.
That said I do think the shell uses the screen poorly from a UI perspective, so it would be nice to combine the best of both worlds somehow. I guess the obvious architecture is to have the GUI in a separate process from the shell itself, so that a crash in the data display code doesn’t bring down the shell, only the “optional” visualization. Some links here: https://github.com/oilshell/oil/wiki/Interactive-Shell
Contrarian viewpoint: I seem to see Bret Victor referenced all over the place in terms of visual programming environments. And I enjoyed his talks and a lot of what he says is insightful and true.
However what I don’t see acknowledged is that visual programming environments are sort of “backward looking” or almost regressive. They rely on someone else to blaze a trail for you. Someone else has to envision what you want to do with the computer and provide you with a nice environment to do it.
This is as opposed to the Unix philosophy of building your own tools. That is, language-oriented programming or DSLs are a way to get some leverage on the future. You can build up ideas that haven’t been thought before. They are more “generative”, whereas visual environments are more like a “framework” that you fit within.
In the future there will be many different types of programming that we haven’t thought of now. Programming is more diverse than it’s ever been, and that trend will continue.
Some examples of things on the edge: quantum computing (apparently Rigetti computing is working with Lisp-based DSLs for this), languages that allow reasoning about privacy and information flow, languages that let you write constant time crypto, etc.
From the recent past: big data frameworks (MapReduce, spark, cloud dataflow, tensorflow) are basically programming languages, and they make visual development tools for desktop obsolete. In fact they make shells and terminals more important, and almost all IDE features less useful. In other words, they require their own separate dev tools that lag behind the language itself.
I doubt any of the future-facing things will be addressed by visual programming environments or visual languages. In other words, visual programming has an inherently limited view of computing. It’s backward looking rather than forward looking.
On the flip side, almost all programming is not doing something inherently new, so there’s still value to coming up with better tools. But it seems like the lag time is very long. That paper was written in 1989, and a lot of the problems still persist.
I have worked with Matlab/Simulink, and I found it pretty good for control systems and state machines.
The lack of diff tool made work with it hard, but otherwise they have their place in software development, and are pretty useful tools for some tasks.
We don’t need to get rid of text as a UI for code, it works great for a great many of us. We need to get rid of text as storage mechanism and interchange format. If step zero of developing a new tool for your language wasn’t “re-parse this dead text and create a new graph that doesn’t interact with anything else” we’d see a lot more movement and progress in tooling.
I’ve done a lot of programming in LabVIEW before I even started programming in a text-based language. It’s not something you can get for free, except a student version. But apart from that it has
Though huge single programs can get as problematic as a huge programs in single text files. I can still recommend it if you want to learn programming but you want more than what Fischertechnik or Lego has to offer. I added some of my hobby stuff on github, but they’ll always be locked behind access to a LabVIEW license, otherwise you just have some binary files in git.
I learned how to program in ROBOLAB, which I think is derived from LabVIEW. We used it to program our RCX for FIRST LEGO League. I remember making fairly sophisticated programs in ROBOLAB while still trying and failing to understand C. Textual programming languages didn’t click for me for about 5 years. I don’t know if I would currently be a software engineer if not for ROBOLAB / LabVIEW.
I’d been working with a few people on a visual game making tool for mobile (the entire tool runs on mobile! no desktop involved) + you can also post and play the games in the app. It’s still alpha and there’s no open beta yet, but you can see a video here: https://twitter.com/snikhilesh/status/1245585186135216131?s=21
It has a physics engine built-in and the editor is collaborative and you can make multiplayer games (multiplayer design may be constrained just to make sure there’s a good user experience).
There’s a lot of prior art out there for visual programming things, here’s a slide deck that captures a bunch: https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bEgysfDmb8PDV6iCAjH5JIvaI/edit#slide=id.g1da0625f1b_0_56 (has a bunch of just general tools that include text-based envs too)
I just wanted to add that visual languages can have formal specifications. Statecharts had quite a few attempts at specification and verification.
I worked with Max/MSP/Jitter almost exclusively for about three years (for a stage performance system for an audiovisual artist) and used it occasionally for smaller projects and products over the past 15 years. I would say that the only points listed in the article that are not solved here in a satisfactory way are the extra screen real estate per functionality, portability and support for scoped (non-wire) variables.
The article doesn’t mention some other drawbacks:
However, it would also be interesting to make a list with the benefits. Off the top of my head:
Disclaimer: I currently work at Cycling ’74