Live data from Hacker News

Unit is a general purpose visual programming system

unit.software

21–30 of 84 posts

Re: Unit is a general purpose visual programming system

#21
post #20

Earlier quoted context omitted.

That’s fine though? Ultimately everything you do on the computer is just a representation of bits being shuffled around. That doesn’t diminish its meaning or effective’s of a better user interface.

The problem becomes if the form you're used to working with the code in is very different from the form you need to communicate about it in. In practice every attempt I've looked at either become hard to communicate about the code in, or the visual aspect tends to end up just becoming a secondary visualisation of code that you still treat as textual first. In the latter case, turning it into a better UI is an unsolve…

Better to round-trip to the AST, and have the textual representation be derivative of that (e.g. by a code formatted like Go).

This also makes it easier to verify that you have all the same capabilities in both representations, as the ways of manipulating the AST are enumerable.

Re: Unit is a general purpose visual programming system

#24
post #20

Earlier quoted context omitted.

That’s fine though? Ultimately everything you do on the computer is just a representation of bits being shuffled around. That doesn’t diminish its meaning or effective’s of a better user interface.

The problem becomes if the form you're used to working with the code in is very different from the form you need to communicate about it in. In practice every attempt I've looked at either become hard to communicate about the code in, or the visual aspect tends to end up just becoming a secondary visualisation of code that you still treat as textual first. In the latter case, turning it into a better UI is an unsolve…

Part of the solution is probably to rethink the whole UX context. One interesting example to think about is ProtoFlux, a part of Resonite:

https://youtu.be/70PH5cQQEdQ?si=y4YmhnimzferVpCD

Since you develop inside vr you can also talk about and show the code in the same vr environment.

It's probably at this level we need to rethink stuff to make visual programming practical.

Re: Unit is a general purpose visual programming system

#25
post #20

Earlier quoted context omitted.

The problem becomes if the form you're used to working with the code in is very different from the form you need to communicate about it in. In practice every attempt I've looked at either become hard to communicate about the code in, or the visual aspect tends to end up just becoming a secondary visualisation of code that you still treat as textual first. In the latter case, turning it into a better UI is an unsolve…

Part of the solution is probably to rethink the whole UX context. One interesting example to think about is ProtoFlux, a part of Resonite: https://youtu.be/70PH5cQQEdQ?si=y4YmhnimzferVpCD Since you develop inside vr you can also talk about and show the code in the same vr environment. It's probably at this level we need to rethink stuff to make visual programming practical.

But then you want to write about it and explain it to someone else, and you're back to needing a way to represent it that fits on a page or can be explained verbally.

Re: Unit is a general purpose visual programming system

#27
post #25

Earlier quoted context omitted.

Part of the solution is probably to rethink the whole UX context. One interesting example to think about is ProtoFlux, a part of Resonite: https://youtu.be/70PH5cQQEdQ?si=y4YmhnimzferVpCD Since you develop inside vr you can also talk about and show the code in the same vr environment. It's probably at this level we need to rethink stuff to make visual programming practical.

But then you want to write about it and explain it to someone else, and you're back to needing a way to represent it that fits on a page or can be explained verbally.

ProtoFlux is largely explained through tutorial videos I think. And I'm not saying that is superior. But I can imagine a lot of quality of life features around explaining it through voice that could be added to make it potentially superior or at least competitive.

You could for example explain every node verbally and visually to an AI bot that can then explain it to the next person, or selectively retrieve parts of your explanations on demand. (OK, I realize that sounds unnecessary complex.)

Re: Unit is a general purpose visual programming system

#28
post #20

Earlier quoted context omitted.

The problem becomes if the form you're used to working with the code in is very different from the form you need to communicate about it in. In practice every attempt I've looked at either become hard to communicate about the code in, or the visual aspect tends to end up just becoming a secondary visualisation of code that you still treat as textual first. In the latter case, turning it into a better UI is an unsolve…

Better to round-trip to the AST, and have the textual representation be derivative of that (e.g. by a code formatted like Go). This also makes it easier to verify that you have all the same capabilities in both representations, as the ways of manipulating the AST are enumerable.

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 constrain yourself to something that can be represented in a readable manner in a textual form, it turns out to be really hard to get to a point where the visual form is easier to work with.

E.g. something as basic as how you comment code in ways that roundtrips nicely is an unsolved problem.

If I have code represented as a graph, I'd be inclined to want to label relationships and dataflows that would be hard to place textually in a way that is meaningful in a textual version and that would roundtrip back to labels in the right place in the visual version.

I've not seen any attempts at visual code that gets even that right.

I've not managed to get it right myself either. If you force users to use an editor built into this tool, and edit a textual representation where some information is hidden, you can do better, but then if people e.g. copy a textual representation of the code into another application and back in, you end up with a mess.

Again, I want to be proven wrong about this. Badly. I love the idea. I've just seen enough failed attempts (and made enough failed attempts) to be disillusioned about it.

Re: Unit is a general purpose visual programming system

#29
post #25

Earlier quoted context omitted.

But then you want to write about it and explain it to someone else, and you're back to needing a way to represent it that fits on a page or can be explained verbally.

ProtoFlux is largely explained through tutorial videos I think. And I'm not saying that is superior. But I can imagine a lot of quality of life features around explaining it through voice that could be added to make it potentially superior or at least competitive. You could for example explain every node verbally and visually to an AI bot that can then explain it to the next person, or selectively retrieve parts of y…

Requiring me to watch videos to follow along is an absolute non-starter to me. It's way too slow. If it was just learning an environment maybe I could tolerate that, but the showstoppers is communicating about code for projects. An AI bot doesn't solve this - if you can't relay the information textually, there's no reason the AI bot will be able to.

Re: Unit is a general purpose visual programming system

#30
post #28

Earlier quoted context omitted.

Better to round-trip to the AST, and have the textual representation be derivative of that (e.g. by a code formatted like Go). This also makes it easier to verify that you have all the same capabilities in both representations, as the ways of manipulating the AST are enumerable.

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 the user need to interact with the textual representation?

Commenting needs to be solved at the language level, and there are many languages that have solved this exact problem. Python, newLISP, and Smalltalk IIRC all have methods for docstring commenting APIs such that the docstring is available as text to the running program / REPL. Use similar syntax to allow any statement to have comments attached, and use this instead of free-form /* */ comments.

Post reply on HN