This seems like a great endeavor.

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.

I'm eager to try out Enso.

> why visual languages have not thrived

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've always wondered why visual languages have not thrived. Is it because the spaghetti gets unmanageable?"

Clicking is way slower than coding.

Allowing both requires some sophisticated compilers and frameworks.

"Can't you have boxes (modules/class/namespace etc) to neatly arrange things?"

But yes you can, which is my approach. It was kind of hard, though and took a little longer than expected, but hopefully you can see the result soon.

>Clicking is way slower than coding.

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.

"I think w/ a suitable UI it doesn't need to be."

Trust me, I tried. You can definitely reach a fast workflow, but typing + shortcuts will be way faster.

But you can combine both.

I think you overestimate how fast some folks type, and how much syntax errors impact productivity.

totally and even without an ergonomic UI, some languages require you to type and go through so many hoops you'd rather click

> I've always wondered why visual languages have not thrived.

Some have, e.g. LabVIEW https://en.wikipedia.org/wiki/LabVIEW

It's a niche UI that has trade-offs.

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.

This is one of the systems discussed in a recent talk that had a couple of threads on HN:

Stop Writing Dead Programs - https://news.ycombinator.com/item?id=33270235 - Oct 2022 (60 comments)

Stop Writing Dead Programs [video] - https://news.ycombinator.com/item?id=33251799 - Oct 2022 (230 comments)

This looks awesome.

I find the problem with visual programming is that often there is multiple representations or diagrams that would be useful to combine and render into a program.

* A box and line diagram with arrows is enough for representing event handlers and event dispatchers and message queues automatically.

* There's multiple approaches or methods to think of a computation: pipeline, communication, mathematic operations, projection. Each of these can be visualised.

* Behaviour composition - how do you combine behaviours together visually? Too many things on the screen and the underlying insight to the problem becomes hard to see or notice.

I'm working on a representation of code that is visual but it's not traditional.

https://github.com/samsquire/structural-visualization

My initial reaction, from an SEng POV, is that visualising code in this way is pointless: the text of the code is the graph of the code. And if you really really value an identity here, use lisp.

So visual coding, for SEng, I think just is pointless. The text isnt the hard part, the hard part the is mental model -- and visuals often impair the quick exploration (etc.) needed to build the mental model.

Likewise, in the YT video introducing this, the creator distinguishes between "code" and your mental model of its execution, as if the latter can and should be ditched. This, of course, is a fallacy as far as SEng is concerned. The whole point is the mental model.

Nevertheless, after watching for longer, the sales pitch here seems directed towards data science (, + DEng perhaps) where applications are often trivial amounts of code.

Coupled with interactive visualisations, this is at least a more plausible use-case.

There the creator's distinction between "how the machine runs your code" and "the problem you're trying to solve" makes more sense. Since practitioners arent building automation systems, apps, etc. they're using code instrumentally to arrive at an outcome.

Also, cf. https://enso.org/docs/developer/enso/enso-philosophy.html

Graphical representations tend to be better than 2D text when dealing with concurrent streams of execution. You can do it in plain text, but either it is difficult to follow or it becomes a mess of text alignments.

IME.

Perhaps, but how much of that it just an imperative phrasing?

I think the visual capabilities of horizontal and vertical spacing are, certainly, vastly under-used.

We could easily divide regions of files into two 60chr lines, or many 20char lines,

    GetWater            .
    Boil(Water)         |
                        | GetCoffee, GetMilk, GetCup .
    Grind(Coffee)       | 
                        | Pour(Milk) .
    Brew(Coffee, Water) .
    Pour(Coffee)        .

But you quickly come up against problems of text alignment, trying to show 2+ theoretical streams of text on one 2D page, and it's a pig to get the DX right. A specialist editor would help, but then you could ask, why not just use a structured doc in eg JSON and represent it graphically.

For background, I wrote a tool that would convert an ASCII art diagram in comments describing the state flow of a class into a set of method declarations in the class. Even using online diagramming tools, it's not easy.

this sounds good for pure concurrent processes. but synchronization will be harder to represent using vertical bars.

This is the route I've been going w/ my work on 3D --- I program in BlockSCAD and make modules for each component, or aspect of a component, and then the design can be visualized as the options/logic which arrive at a particular iteration.

>visuals often impair the quick exploration (etc.) needed to build the mental model.

If that was true why do we use whiteboards do much?

their image processing example on the github readme is compelling

I sort of agree that they're conflating a few things:

- resumable processes

- text graph description format

- using graph descriptions to lint or generate code

- UX / visualization for graphs

But I could be convinced that these are things that go better together

Narrator at 0:25 in video: "All of these things can be done without writing a single line of code"

Demo at 2:10: [Narrator begins writing many lines of code in a proprietary language]

Not saying this is a bad tool, but the breathless "no code!" hype is a bit much.

Modern FPGA designs actually work very similarly. You have a high level graphical representation of all the different modules and IP cores you use, and connect their inputs and outputs together using the GUI, but then the actual "code" (VHDL/Verilog/etc.) inside those modules is still written in text form like normal programming languages.

A long time friend of mine is their advisor I believe. So I am pretty confident that the engineering is outstanding

crosslinking to relavent subreddits

https://old.reddit.com/r/futureofprogramming

https://old.reddit.com/r/nosyntax

Also the name of dmenu, Quicksilver like application.

https://alternativeto.net/software/enso/about/

First thing that name brings to my mind. That said it's a very niche long-dead (unfortunately) product.