I have seen dozens of these things and have made a few myself.
Beyond some specific use cases, they don't seem to scale cognitively. The tangle of connections is a problem. The previous HN link from @andsoltis has a better critique than me.
Don't get me wrong. Besides being experientially cynical about these things, I'm also firmly in the camp of "one more UI breakthrough, bro and we might crack it!"
This one has some deep design that definitely attempts to extend the state of the art but still struggles with that aforementioned problem.
TBH though, the coolest feature is that widget that focuses on what you are doing. There is something there with it, I'm just not sure what the "there" or "it" is, but I do know I like it.
I spent a lot of time on this too, many years ago, including working on a language designed specifically for it, and my conclusion was that I couldn't find a way to make it work without making the visual representation "just a tool" for working with a textual representation, because we still need to be able to communicate about code in all kinds of context where a largely visual system would mean being forced to share screenshots, as well as being able to handle e.g. diffs and source control. And once you still need to know and understand and work with a textual representation it feels like a lot of the potential evaporates, and that made me gradually lose interest.
I'd love it if someone found a solution to that, but it feels like an intractable problem beyond some specific use cases as you say.
I use such tools when I can, and am fascinated with the concept, since it evokes Herman Hesse's _Glass Bead Game_ (from his novel _Magister Ludi) which was a book I remember fondly from my youth.
Advantages are:
- discoverability --- it seems pretty easy to arrange all elements in a hierarchy and make them accessible via clicking/revealing
- no syntax errors --- if things fit together/connect, then it should be a syntactically valid program
The problem is, it relies on a couple of concepts we don't seem to have a good solution for:
- What does an algorithm look like?
- How to deal with an algorithm which is larger than the current screen/window size? (it's all-too easy to have the same sort of problem of a not-wrapped program with lines longer than the current window size and more lines than will fit in a window, and there doesn't seem to be a 2D graphical equivalent of turning on word-wrapping)
- If programs are broken down into discrete modules, then connected together, one is back to the wall-of-text description which presumably one was trying to escape from, just wrapped up in boxes and connectors
I used LabVIEW extensively in the past. It was possible to organize code for readability, but it was physically laborious and I got massive eyestrain headaches and wrist fatigue from all of the fine mouse work needed. To be fair, maybe that's a personal ergonomic issue. I also can't use CAD for the same reason.
I can sling text with my eyes closed, and have managed the ergonomics of typing well enough that it hasn't injured me in almost 50 years.
On the other hand for applications where dataflow was a good paradigm for the problem being solved, I appreciated its benefits.
> Beyond some specific use cases, they don't seem to scale cognitively. The tangle of connections is a problem.
This just isn't true. I've actually built things in visual languages. It just requires the same organization as text-based languages. One could write an entire text-based program in a single file in a single function, which would be a similar mess. In fact, the benefit or feature of visual languages is that they showcase poor code more readily than text-based code.
Beyond some specific use cases, they don't seem to scale cognitively. The tangle of connections is a problem.
Tons of things like this were built in Smalltalk. (Including a UI->Domain model connection layer in the IBM VisualAge Smalltalk IDE.) They all had scaling problems, especially, "they don't seem to scale cognitively."
It's not as if the problem doesn't exist in most codebases. It's more that the problem is invisible without such tools. Tools making the tangle visible make themselves seem unusable.
The fundamental problem, is that we don't have ways of introspecting these horrendous relationship graphs for specific contexts. If IDEs and other programming tools generally could create custom browsers/IDE windows for things based in queries like:
"All of the methods that contain references to ClassA.Member1 and ClassB.Member2 which also call function Y."
...where this query can be modified or further specified at runtime. Then there could be specific built in queries that cover everything touched by canned refactorings. Then these further could be intersected or unioned.
EDIT: Forgot to complete my thought. If the graphical diagram could show contextually relevant slices of the system, it would greatly cut down the confusing web aspect of the diagrams.
I discovered Unit in the latter half of 2022 and found it very interesting. I always loved Fusion and Houdini for the flow based programming aspects. I think in Houdini's case it is notable that is has such a long history it dates back to earlier research in visual computing...
Anyway, I used Unit as an excuse to play with OBS and stream a bit... if you'd like to see a video of how I figured out some bits about how it worked since I couldn't find anything close to a tutorial I have a video on YouTube:
Thank you for posting this! It confirms my suspicion that Unit is probably not reinventing the meaning of computation to match the new visual medium? But still quite interesting how it is laid out.
This is quite comparable to the vision I had in 2012 for NuzzGraph, but there was no way I was going to realistically make any real progress given the complexity and my lack of experience at the time.
Also it was clearly a solution in search of a problem. I was a believer in the idea that graph databases would enable a new paradigm of application development in the way that relational databases did, and wanted to try to pioneer something. That was (so I thought) what college dropouts like myself in my early 20s needed to do to get ahead in tech, as I was only a mere data analyst at the time, with no connections to the tech industry, scraping by while living inside a garage.
It was a good exercise though and it somehow out of sheer luck caught the attention of Manning Publications as it likely came up in the search results for OrientDB. My project page included a sort of roadmap to integrate with OrientDB.
They signed me on as a co-author of the book OrientDB in Action as the other author(s) IIRC weren’t native English speakers and they needed one. The book was never released but a different author released a similar book without publisher backing which was good enough for OrientDB.
If a publisher ever approaches you to help write a book, no matter how ridiculous of a candidate you think you are, your initial response should always be yes. You don’t have any obligation to actually finish a book unless it’s in the contract. You won’t make a dime but you’ll get world-class training on writing technical documentation. They only required that I complete a draft of one chapter within a shorter timespan for the first phase.
I've probably mentioned this a few times on here, but Prograph was a GREAT example of a visual language, that solved a LOT of issues (spaghetti code) etc. It's worth a look if you're interested in visual programming
* object oriented
* scrunching of code - tha could be turned into functions (local-to-opers)
* you could edit code and values whilst it was running
* FAST!
Here's an ole video of some server software I made, that at the end shows me rustily doing some Prographing.
Love unit, long time admirer. If you're into this, you might also be into Substrate - a non-visual but also graph-based programming model, for multi-step ML programs https://www.substrate.run/
I think the future is in mixed modal computing environments. Text is superior in some architectural paradigms and inferior in others.
Box and noodles can be more descriptive and interactive for some parts of a system but probably not for all parts of a system. Configurations for parts of applications can be better in a GUI than a yaml file. Embedding one language like SQL in another could have an integrated GUI subeditor complete with language server.
Visual/graphical like this I think should be layer of abstraction above traditional text code. With the express purpose of search/reuse (especially by less skilled computer users)
1) So a user creates a couple of nodes in a graph: a button, his specific hardware, a text node saying he wants to calcuate clicks per day.
2) This graph is then used to find published graphs by people who have used these nodes in a completed/deployed instance.
3) The user can easily browse and pick an exact complete graph to deploy himself. (layers here such as preventing private wifi passwords from getting to the published graphs)
4) If the graph is complete in terms of pointing to his exact hardware, exact code chunks as nodes, exact sdk versions then it transforms this graph into typical source code, and can be compiled and deployed, and after confirming it works, then shared again to the public graph collection to let others know it works.
5) if the graph isn't complete, you might have to write some code chunk nodes, connect things properly, or else use AI (har har) or even mark nodes as "todo: can someone please implement this code, or pledges/bounties for someone to help implement"
6) People need to be able to jump into any level they are comfortable with, the code, the graph shape, the public list of TODOs. Then there is translation/generation into the other levels. This makes a tool for higher level collaboration, that should be able to converge on finishing off desired solutions.
The whole point being a new level of abstraction that makes code reuse possible if someone has implemented the same thing in the past already. (but even if it was on different hardware/sdk there should be reusable stateless functional-style code that can be stitched together a bit easier)
The flow based visual programming has always being challenging field, and the problem remains: what are the values added comparing with the text based coding?
I really want to love it, please give me a strong reason.
Debugging is quite nice. Clicking on a wire and being able to visually see its value at runtime and even present it in a custom UI, like a graph or chart, is awesome.
It's easier to parallelize a flow graph than a sequential series of instructions. (This is why visual flow programming caught on in embedded hardware and IoT.)
DrMiaow|1 year ago
Beyond some specific use cases, they don't seem to scale cognitively. The tangle of connections is a problem. The previous HN link from @andsoltis has a better critique than me.
Don't get me wrong. Besides being experientially cynical about these things, I'm also firmly in the camp of "one more UI breakthrough, bro and we might crack it!"
This one has some deep design that definitely attempts to extend the state of the art but still struggles with that aforementioned problem.
TBH though, the coolest feature is that widget that focuses on what you are doing. There is something there with it, I'm just not sure what the "there" or "it" is, but I do know I like it.
vidarh|1 year ago
I'd love it if someone found a solution to that, but it feels like an intractable problem beyond some specific use cases as you say.
I really hope I'm wrong.
WillAdams|1 year ago
Advantages are:
- discoverability --- it seems pretty easy to arrange all elements in a hierarchy and make them accessible via clicking/revealing
- no syntax errors --- if things fit together/connect, then it should be a syntactically valid program
The problem is, it relies on a couple of concepts we don't seem to have a good solution for:
- What does an algorithm look like?
- How to deal with an algorithm which is larger than the current screen/window size? (it's all-too easy to have the same sort of problem of a not-wrapped program with lines longer than the current window size and more lines than will fit in a window, and there doesn't seem to be a 2D graphical equivalent of turning on word-wrapping)
- If programs are broken down into discrete modules, then connected together, one is back to the wall-of-text description which presumably one was trying to escape from, just wrapped up in boxes and connectors
Two pages with cautionary images are:
https://blueprintsfromhell.tumblr.com/
and
https://scriptsofanotherdimension.tumblr.com/
I've been trying to use OpenSCAD Graph Editor: https://github.com/derkork/openscad-graph-editor in my own work:
https://github.com/WillAdams/gcodepreview
and the screen grab from there sums up the difficulties pretty well:
https://raw.githubusercontent.com/WillAdams/gcodepreview/mai...
analog31|1 year ago
I can sling text with my eyes closed, and have managed the ergonomics of typing well enough that it hasn't injured me in almost 50 years.
On the other hand for applications where dataflow was a good paradigm for the problem being solved, I appreciated its benefits.
bmitc|1 year ago
This just isn't true. I've actually built things in visual languages. It just requires the same organization as text-based languages. One could write an entire text-based program in a single file in a single function, which would be a similar mess. In fact, the benefit or feature of visual languages is that they showcase poor code more readily than text-based code.
stcredzero|1 year ago
Tons of things like this were built in Smalltalk. (Including a UI->Domain model connection layer in the IBM VisualAge Smalltalk IDE.) They all had scaling problems, especially, "they don't seem to scale cognitively."
It's not as if the problem doesn't exist in most codebases. It's more that the problem is invisible without such tools. Tools making the tangle visible make themselves seem unusable.
The fundamental problem, is that we don't have ways of introspecting these horrendous relationship graphs for specific contexts. If IDEs and other programming tools generally could create custom browsers/IDE windows for things based in queries like:
"All of the methods that contain references to ClassA.Member1 and ClassB.Member2 which also call function Y."
...where this query can be modified or further specified at runtime. Then there could be specific built in queries that cover everything touched by canned refactorings. Then these further could be intersected or unioned.
EDIT: Forgot to complete my thought. If the graphical diagram could show contextually relevant slices of the system, it would greatly cut down the confusing web aspect of the diagrams.
leetrout|1 year ago
Anyway, I used Unit as an excuse to play with OBS and stream a bit... if you'd like to see a video of how I figured out some bits about how it worked since I couldn't find anything close to a tutorial I have a video on YouTube:
https://www.youtube.com/watch?v=vwknTfGVDq8
crdrost|1 year ago
webprofusion|1 year ago
DarkNova6|1 year ago
andsoitis|1 year ago
Related: A personal history of visual programming environments (Dec 2022); 27 comments https://news.ycombinator.com/item?id=34094223
paulhart|1 year ago
leke|1 year ago
deegles|1 year ago
This readme gives a much better idea of how it works: https://github.com/samuelmtimbo/unit/blob/main/src/docs/star...
brabel|1 year ago
Example: https://github.com/leofds/iot-ladder-editor Fiddle: https://www.plcfiddle.com/
Real world: Siemens SIMATIC for S7 PLCs (this lets you interchange between an Assembly-like language and the visual Ladder logic): https://cache.industry.siemens.com/dl/files/395/18654395/att...
rickcarlino|1 year ago
jimmySixDOF|1 year ago
https://x.com/io_sammt/status/1792251421154316516?t=Glk0hVvo...
Nuzzerino|1 year ago
Also it was clearly a solution in search of a problem. I was a believer in the idea that graph databases would enable a new paradigm of application development in the way that relational databases did, and wanted to try to pioneer something. That was (so I thought) what college dropouts like myself in my early 20s needed to do to get ahead in tech, as I was only a mere data analyst at the time, with no connections to the tech industry, scraping by while living inside a garage.
It was a good exercise though and it somehow out of sheer luck caught the attention of Manning Publications as it likely came up in the search results for OrientDB. My project page included a sort of roadmap to integrate with OrientDB.
They signed me on as a co-author of the book OrientDB in Action as the other author(s) IIRC weren’t native English speakers and they needed one. The book was never released but a different author released a similar book without publisher backing which was good enough for OrientDB.
If a publisher ever approaches you to help write a book, no matter how ridiculous of a candidate you think you are, your initial response should always be yes. You don’t have any obligation to actually finish a book unless it’s in the contract. You won’t make a dime but you’ll get world-class training on writing technical documentation. They only required that I complete a draft of one chapter within a shorter timespan for the first phase.
https://code.google.com/archive/p/nuzzgraph/wikis
https://code.google.com/archive/p/nuzzgraph/wikis/NuzzGraphB...
bobajeff|1 year ago
thomastjeffery|1 year ago
everythingabili|1 year ago
I've probably mentioned this a few times on here, but Prograph was a GREAT example of a visual language, that solved a LOT of issues (spaghetti code) etc. It's worth a look if you're interested in visual programming
* object oriented * scrunching of code - tha could be turned into functions (local-to-opers) * you could edit code and values whilst it was running * FAST!
Here's an ole video of some server software I made, that at the end shows me rustily doing some Prographing.
https://youtu.be/MtECJw59elc?si=svRbd5_IA4cAFhVa&t=1429
p.s A free version of Prograph (Marten) used to exist, but when the genius creator died, the project, sort of lost its way too.
benzguo|1 year ago
mdaniel|1 year ago
> Added `If`
Uh, that's a pretty weird thing to add in a second release
DrMiaow|1 year ago
williamcotton|1 year ago
Box and noodles can be more descriptive and interactive for some parts of a system but probably not for all parts of a system. Configurations for parts of applications can be better in a GUI than a yaml file. Embedding one language like SQL in another could have an integrated GUI subeditor complete with language server.
beefnugs|1 year ago
1) So a user creates a couple of nodes in a graph: a button, his specific hardware, a text node saying he wants to calcuate clicks per day.
2) This graph is then used to find published graphs by people who have used these nodes in a completed/deployed instance.
3) The user can easily browse and pick an exact complete graph to deploy himself. (layers here such as preventing private wifi passwords from getting to the published graphs)
4) If the graph is complete in terms of pointing to his exact hardware, exact code chunks as nodes, exact sdk versions then it transforms this graph into typical source code, and can be compiled and deployed, and after confirming it works, then shared again to the public graph collection to let others know it works.
5) if the graph isn't complete, you might have to write some code chunk nodes, connect things properly, or else use AI (har har) or even mark nodes as "todo: can someone please implement this code, or pledges/bounties for someone to help implement"
6) People need to be able to jump into any level they are comfortable with, the code, the graph shape, the public list of TODOs. Then there is translation/generation into the other levels. This makes a tool for higher level collaboration, that should be able to converge on finishing off desired solutions.
The whole point being a new level of abstraction that makes code reuse possible if someone has implemented the same thing in the past already. (but even if it was on different hardware/sdk there should be reusable stateless functional-style code that can be stitched together a bit easier)
wangii|1 year ago
I really want to love it, please give me a strong reason.
bmitc|1 year ago
otabdeveloper4|1 year ago
imtringued|1 year ago
unknown|1 year ago
[deleted]
remon|1 year ago