Hacker News new | ask | show | jobs
by illiarian 1190 days ago
> visual programming has never taken off, despite countless attempts over the past few decades.

It has, in some niches like Unreal Blueprints.

I think one of the reasons it doesn't become more popular is because most visual programming is just a more cumbersome and slow way of programming. It's stringing the same concepts together in the same way, but slowly and tediously with a mouse.

Non-tech users wouldn't know what to do with it. Power users would rather program directly.

4 comments

I find dragging-dropping and re-arranging far more expressive for 3D modeling using BlockSCAD than I do the equivalent OpenSCAD code:

https://www.blockscad3d.com/editor/

I'm trying to achieve a similar fluency using OpenSCAD Graph Editor:

https://github.com/derkork/openscad-graph-editor

hopefully a future version will be even more useful than BlockSCAD/Blockly.

Originally Ruby had a Blueprints-like UI to connect an event fired by one gizmo to a property of another gizmo. You would right-click a gizmo, select an event, drag a line over to the target gizmo and select a property.

In fact when Ryan first contacted me about the article, he was looking for a screenshot of this UI. Alas, I didn't have anything.

When Microsoft turned Ruby into VB, they abandoned this UI and just kept the form designer with Basic as a scripting language.

> You would right-click a gizmo, select an event, drag a line over to the target gizmo and select a property.

This idea lives on in Qt Creator - https://doc.qt.io/qt-6/designer-connection-mode.html although I think most larger apps write their `connect()` calls in code instead.

Was it kind-of like this?

> It has, in some niches like Unreal Blueprints. [...] I think one of the reasons it doesn't become more popular is because most visual programming is just a more cumbersome and slow way of programming. It's stringing the same concepts together in the same way, but slowly and tediously with a mouse.

The latter bit basically perfectly describes Unreal Blueprints :-P.

It was hyped when it first came out and for some time (years) it was well received - until people had to deal with the spaghetti mess others made in blueprints.

Visual languages are fine as long as they are limited to high level concepts, but UB not only is not that (there is even a type cast node!) but instead of being there in addition to Unreal Script, it actually replaced it, forcing many people who didn't want to bother with C++ (especially Unreal's flavor of C++) to use blueprints.

Epic supposedly learned from this and UE5 at some point will have a new scripting language, but AFAIK so far it has been vaporware. Meanwhile i (i am into gamedev and have worked with UE) increasingly see people get disillusioned by Blueprints.

I'm the last to defend visual programming, it's mostly spaghetti nonsense and you'd be better of with an actual programming language for most complexity levels -- but I think there's a viable niche for stuff that satisfies both of the following:

(a) it's simple and it strings together off-the-shelf components;

(b) it has an intuitive, well-defined computational model

examples: defining compositions of matrix transformations for camera angles, defining data pipelines (read from this source, do these operations, write to that sink), very simple automation Apple Shortcuts-style (whenever I receive a message from this number, make a note on this file, etc.)

As soon as you venture into general-purpose territory, visual programming is just a disaster. Which is a problem because you have no way to convert your mini-idea into something usable, and you always find yourself wishing you had started with a normal script.

I tend to stay very far away, but it does have its moments admittedly.

The thing is, using modules it should be possible to create even higher-level concepts, so things should become more expressive --- that's how I work in BlockSCAD.

The problem always becomes such expressions become just a list of names of modules and their inputs, so one is back to the wall-of-text problem which a visual tool is supposed to solve --- the fundamental issue is, "What does an algorithm look like"?

and the solution we need is, "What is the most expressive way to create algorithms"?

BP is the only reason I don't want to play with UE. It's too painful IMHO. I wish we had Unrealscript.