Unit is a general purpose visual programming system • Hacker News Board

Re: Unit is a general purpose visual programming system

#41

Post by WillAdams » Mon, Jul 08, 2024, 1:33 PM UTC

DrMiaow wrote: post #14

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 som…

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

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...

Re: Unit is a general purpose visual programming system

#42

Post by jimmySixDOF » Mon, Jul 08, 2024, 1:52 PM UTC

rickcarlino wrote: post #40

DNS is not resolving for me. Is this an HN hug of death? Anyone have a link to GitHub or similar?

They are pretty active on xTwitter if you want to see some samples :

https://x.com/io_sammt/status/1792251421154316516?t=Glk0hVvo...

Re: Unit is a general purpose visual programming system

#43

Post by [deleted] » Mon, Jul 08, 2024, 2:13 PM UTC

adastra22 wrote: post #30

vidarh wrote: post #28

Earlier quoted context omitted.

Many people have tried that. I built a language and UI around that way back, and many others have. I ditched mine because there were way too many unsolved problems I felt made it useless. The problem is that if your primary means of working with the code is visual, the textual representation of your code then tends to be foreign to you when you're trying to use it to communicate aspects of the code, and when you cons…

Why would you want to work with the text representation, except when debugging or in the backend? I mean I get why you'd want the text representation to exist--we have mountains of infrastructure around text-based representations of code. Git for version control and LLM code models would work out of the box, for example. But that can all be handled on the backend by transpiling the AST to text as needed. Why would th…

[deleted]

Re: Unit is a general purpose visual programming system

#44

Post by bmitc » Mon, Jul 08, 2024, 2:13 PM UTC

patrick451 wrote: post #37

bmitc wrote: post #32

Earlier quoted context omitted.

> 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…

I have also actually built things in a visual programming language. They are simply not capable of the same level of organization as a text based language because pictures is a bad way to communicate. There is a reason humans advanced past cave painting and hieroglyphics.

Are you able to elaborate more? What language?

I have used LabVIEW, among other visual languages, and built systems with 1,000+ VIs, which are the fundamental building blocks of code organization, and hundreds of classes. LabVIEW has VIs, clusters, classes, libraries, and projects, all of which are useful and required for a well-managed, decoupled code system.

With good software principles, there's nothing that says you can't organize and scale visual code well.

I one time interviewed at a place that had swore off LabVIEW and were moving to Python. The reasons of switching from LabVIEW were the same tired reasons of organizational issues. When I asked to see their Python code, they showed me a single Python file over 10,000 lines long, and there were function signatures that were over 20 lines long. That was just the function signatures. This example, along with many more, and my experience in both visual languages and text-based languages make me very skeptical about claims about not being able to organize and scale code in visual languages.

Re: Unit is a general purpose visual programming system

#45

Post by Nzen » Mon, Jul 08, 2024, 2:40 PM UTC

vidarh wrote: post #33

adastra22 wrote: post #30

Earlier quoted context omitted.

Why would you want to work with the text representation, except when debugging or in the backend? I mean I get why you'd want the text representation to exist--we have mountains of infrastructure around text-based representations of code. Git for version control and LLM code models would work out of the box, for example. But that can all be handled on the backend by transpiling the AST to text as needed. Why would th…

> Why would you want to work with the text representation, except when debugging or in the backend? How would I communicate about the project to others in e-mails, instant messenger, face to face, in blog posts, in articles, in books? How would I review diffs of code changes effectively? That is why. Find me a representation I can talk about and write about efficiently without screenshots or videos or requiring speci…

I think that it is probably worth addressing what sort of textual visualization you have in mind. That way, you could disabuse people with naive notions like myself.

I've not used a visual programming language and unit is (currently) hugged to death. But, my experience with graphviz's dot syntax would suggest putting a comment on the (textual) line that represents the edge itself:

  digraph whatever {
    running [ shape = "triangle" label = "program running" ]; # comment on the node itself
    stopped;
    running -> stopped; # comment about the edge
    stopped -> running;
  }

I acknowledge, though, that I'm thinking of this as a dsp-style situation, where a node only connects at its boundaries, rather than in the center (say if a node contains code that would link to another as part of an if expression's body).

(Also, I'm disappointed that I need to resist the urge to talk about Bob Nystom's visual pdf diff, because it seems really cool but is not as credible as the edge directive above. https://journal.stuffwithstuff.com/2021/07/29/640-pages-in-1... , scroll to 3/4 where it says "Here is what all of the proofreading changes look like:")

Re: Unit is a general purpose visual programming system

#46

Post by beefnugs » Mon, Jul 08, 2024, 2:47 PM UTC

williamcotton wrote: post #39

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 subed…

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)

Re: Unit is a general purpose visual programming system

#47

Post by Rhapso » Mon, Jul 08, 2024, 2:52 PM UTC

WillAdams wrote: post #41

DrMiaow wrote: post #14

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 som…

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 syn…

Looking at those, I feel like we are approaching the problem entirely wrong.

Even in text, you don't try and look at everything at once, zooming out for a "structure overview" seems useful, but that is not what is happening here, its just imperative code being shoehorned into a DAG and left wherever a user left it instead of organizing itself, which is the whole benefit to graphical programming.

This demo of "unit" at least seems to organize nodes and views of nodes better.

Re: Unit is a general purpose visual programming system

#48

Post by vidarh » Mon, Jul 08, 2024, 3:28 PM UTC

Nzen wrote: post #45

vidarh wrote: post #33

Earlier quoted context omitted.

> Why would you want to work with the text representation, except when debugging or in the backend? How would I communicate about the project to others in e-mails, instant messenger, face to face, in blog posts, in articles, in books? How would I review diffs of code changes effectively? That is why. Find me a representation I can talk about and write about efficiently without screenshots or videos or requiring speci…

I think that it is probably worth addressing what sort of textual visualization you have in mind. That way, you could disabuse people with naive notions like myself. I've not used a visual programming language and unit is (currently) hugged to death. But, my experience with graphviz's dot syntax would suggest putting a comment on the (textual) line that represents the edge itself: digraph whatever { running [ shape =…

> I acknowledge, though, that I'm thinking of this as a dsp-style situation, where a node only connects at its boundaries, rather than in the center (say if a node contains code that would link to another as part of an if expression's body).

I think that might well be one of those restricted situations where visual programming often works well enough that it seems some use. I'm absolutely not saying it can't ever work.

My problem with it is more when you try to do more general-purpose things with it, and you e.g. either end up with a node per method/function call (and maybe then even nodes for argument expressions) or large, complex nodes with internal logic.

I love dot for graphs, but the challenge to me with that approach is that I've not seen a convincing example where you'd then not end up with a mountain of text for even very simple things (and I've sinned badly there myself - one of my own early attempts serialised to XML...) when you decompose the text enough that you can augment it reliably.

E.g. consider a complex expression where that edge is not just a simple state transition, but a method call with arguments, where each argument itself might be a complex expression...

Every attempt I made myself ended up with a textual version that was too verbose to feel viable for communication about the code unless I stripped out so much that the visual tooling effectively became a tool to analyse the textual version, rather than allowing editing on equal footing.

Re: Unit is a general purpose visual programming system

#49

Post by WillAdams » Mon, Jul 08, 2024, 3:34 PM UTC

Rhapso wrote: post #47

WillAdams wrote: post #41

Earlier quoted context omitted.

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 syn…

Looking at those, I feel like we are approaching the problem entirely wrong. Even in text, you don't try and look at everything at once, zooming out for a "structure overview" seems useful, but that is not what is happening here, its just imperative code being shoehorned into a DAG and left wherever a user left it instead of organizing itself, which is the whole benefit to graphical programming. This demo of "unit" a…

Sort of?

One of the really nice things in Literate Programming

http://literateprogramming.com/

is that one gets a nicely typeset PDF which has a hyperlinked ToC which does serve as a "structure overview": https://github.com/WillAdams/gcodepreview/blob/main/gcodepre...

I agree, some facility for automatic re-organization and adjusting what is shown/readable in terms of hierarchy based on how much or little of the program is being shown would help a lot.

Re: Unit is a general purpose visual programming system

#50

Post by nkcmr » Mon, Jul 08, 2024, 4:00 PM UTC

DarkNova6 wrote: post #35

webprofusion wrote: post #22

Pro tip: before launching on HN stick your site behind Cloudflare first so they can cache most of your traffic.

Or at the very least make an internet archive snapshot…

Which Cloudflare can also do for you: https://blog.cloudflare.com/cloudflares-always-online-and-th...