I've always wondered why visual languages have not thrived. Is it because the spaghetti gets unmanageable? Can't you have boxes (modules/class/namespace etc) to neatly arrange things?
> GraalVM, Performance meets polyglot
> Import any library from Enso, Java, JavaScript, R, or Python
A use of GraalVM in the wild! Seems like a perfect fit for this project. Can it use the C-accelerated libs from Python like numpy? I always thought it was up to the programmer to make libs go through Sulong, then bind things later on.
In my experience, "visual" gets you ~90% to done. But inevitably, you have to drop to code. To handle the use cases and edge cases not anticipated by the framework. And then you're fighting the framework. Which is a 800lb angry gorilla sitting between you and your goal.
For flowchart & block style programming, the pitfall is the error handling.
For patch cord style programming, the pitfall is conditional behavior and any data flows which are not 1:1 input-to-output. (Non-1:1 use cases are a challenge for all ontology/taxonomy systems, more generally.)
There's a few visual languages I would say have thrived like Labview and UnrealEngine, a couple things in the real time audio/visual space I forget the name of, etc.
But beyond those niches it hasn't caught on.
One reason for this is editing is awkward. With text you can have things in a broken intermediate state while you make changes, copy and paste, etc. The tools for doing this with a visual graph end up being more awkward and slow vs a programmer practiced with their editor/ide.
And the other problem is the graphs become a huge mess past some threshold of complexity. Even with boxes it's bad. This is a very common complaint about LabView. Example: http://forums.ni.com/legacyfs/online/4106_spaghetti.gif
I'm very skeptical a visual language will catch on for programming in general.
I think w/ a suitable UI it doesn't need to be. Things which need to be addressed:
- it should be easy to instantiate new objects
- minimize scrolling/present lists of choices efficiently --- when using the Blockly version of OpenSCAD, BlockSCAD I often wish that the variable list could be made hierarchical so that the variables from a particular module could easily be identified or limited to
- being able to collapse blocks of code and expand them is very powerful
Trying to get over my aversion to Electron wrappers to try this out.
Perhaps un-intuitively, a 2D/3D continuous medium (i.e. a picture) is less expressive than a 1D discreet symbolic medium (i.e. a script). For example, the picture enforces a notion of nearness, of distance, whereas the script need not suffer such strictures (unless explicitly enforced - see GOTO vs structured programming). Thus the simpler topology of the script allows the author a more unfettered medium of expression.
> Can't you have boxes (modules/class/namespace etc) to neatly arrange things?
The limit on how complex a graph program can be before it's impossible to read is extremely low. Plenty of languages have boxes, none that I know about manage to make them fine-grained enough to neatly arrange things.
Also, change is harder. And anything that makes changes harder makes your code less modular.
I've always wondered why visual languages have not thrived. Is it because the spaghetti gets unmanageable? Can't you have boxes (modules/class/namespace etc) to neatly arrange things?
> GraalVM, Performance meets polyglot
> Import any library from Enso, Java, JavaScript, R, or Python
A use of GraalVM in the wild! Seems like a perfect fit for this project. Can it use the C-accelerated libs from Python like numpy? I always thought it was up to the programmer to make libs go through Sulong, then bind things later on.