Unit: A visual programming system [video] • Hacker News Board

Re: Unit: A visual programming system [video]

#31

Post by jayd16 » Thu, Aug 17, 2023, 4:10 PM UTC

worldsayshi wrote: post #27

vadiml wrote: post #17

Reminds me LabView

Which for me begs the question, is LabView worth it? It's the only widely used Visual Programming Language I can think of. Every time someone posts a visual programming language prototype the same claims are made over and over again. Like; adds too much complexity, throws out benefits of text editing, eats up too much screen space etc etc. I'm convinced that many of those issues can be overcome and that until we figu…

> It's the only widely used Visual Programming Language I can think of.

Unreal's blueprints are also very widely used in production.

Re: Unit: A visual programming system [video]

#32

Post by jasfi » Thu, Aug 17, 2023, 4:40 PM UTC

worldsayshi wrote: post #22

jasfi wrote: post #21

I feel like this only adds complexity to code.

We add complexity all the time. In the end it comes down to whether it's worth it.

Maybe as a teaching aid or for sharing/presenting ideas. But I wouldn't use it for day-to-day programming.

Re: Unit: A visual programming system [video]

#33

Post by worldsayshi » Thu, Aug 17, 2023, 7:26 PM UTC

jayd16 wrote: post #31

worldsayshi wrote: post #27

Earlier quoted context omitted.

Which for me begs the question, is LabView worth it? It's the only widely used Visual Programming Language I can think of. Every time someone posts a visual programming language prototype the same claims are made over and over again. Like; adds too much complexity, throws out benefits of text editing, eats up too much screen space etc etc. I'm convinced that many of those issues can be overcome and that until we figu…

> It's the only widely used Visual Programming Language I can think of. Unreal's blueprints are also very widely used in production.

Yeah, is using a visual programming language worth it in that case?

Re: Unit: A visual programming system [video]

#34

Post by IshKebab » Thu, Aug 17, 2023, 7:38 PM UTC

jasfi wrote: post #32

worldsayshi wrote: post #22

Earlier quoted context omitted.

We add complexity all the time. In the end it comes down to whether it's worth it.

Maybe as a teaching aid or for sharing/presenting ideas. But I wouldn't use it for day-to-day programming.

Yeah I think this is fine for programming that you want to be highly discoverable and generally stays below ~100 operations. Good for graphics and audio. Not good for any significant programming.

Re: Unit: A visual programming system [video]

#35

Post by seanc » Thu, Aug 17, 2023, 8:23 PM UTC

worldsayshi wrote: post #27

vadiml wrote: post #17

Reminds me LabView

Which for me begs the question, is LabView worth it? It's the only widely used Visual Programming Language I can think of. Every time someone posts a visual programming language prototype the same claims are made over and over again. Like; adds too much complexity, throws out benefits of text editing, eats up too much screen space etc etc. I'm convinced that many of those issues can be overcome and that until we figu…

Historically LabView had two other key things going for it besides the low-entry-barrier of visual programming.

1. A GUI comes for free; in LabView each program is two windows, each variable you declare shows up once on your code DAG and then again on your GUI as a switch, text box, slider, etc.

2. National Instruments also had a set of libraries and PCI cards for communicating with lab equipment like benchtop power supplies, voltmeters, and even up to big complex kit like oscilloscopes and exotic telecom protocol emulators.

Those two things enabled people to easily wire up a motley assembly of benchtop instruments and orchestrate them together for a unified test of hardware like circuit boards and so on.

Nowadays EE types have better coding skills and those benchtop instruments all have Ethernet ports and REST API's.

But SpaceX famously uses LabView for some things, most notably for the Dragon flight console.

Re: Unit: A visual programming system [video]

#36

Post by Mali- » Thu, Aug 17, 2023, 10:49 PM UTC

The problems spoke for themselves over the course of the presentation. Something as simple as a counter was very complicated to look at, filling the screen with jiggling nodes. The presenter then introduces a bug while trying to decrement, and is unable to debug it.

Re: Unit: A visual programming system [video]

#37

Post by jayd16 » Thu, Aug 17, 2023, 11:45 PM UTC

worldsayshi wrote: post #33

jayd16 wrote: post #31

Earlier quoted context omitted.

> It's the only widely used Visual Programming Language I can think of. Unreal's blueprints are also very widely used in production.

Yeah, is using a visual programming language worth it in that case?

Yes. Non-coders often find it more approachable. These systems are a good fit for games because games have many static assets that need to be referenced. Dragging and dropping to form an asset reference is preferred to using text ids.

Re: Unit: A visual programming system [video]

#38

Post by ericHosick » Fri, Aug 18, 2023, 12:59 AM UTC

Mali- wrote: post #36

The problems spoke for themselves over the course of the presentation. Something as simple as a counter was very complicated to look at, filling the screen with jiggling nodes. The presenter then introduces a bug while trying to decrement, and is unable to debug it.

I spent quite a bit of time (about 8 years) looking into and working on VPLs. What I found was that our perceptions and interactions with various abstractions such as programming, mathematics, or even music (sheet music), are shaped by our individual mental models.

I code using programming languages because it was what I was taught in college and it's what I've used for decades. For me, something like SQL looks amazing and is super easy to rad. Whereas others may see SQL as something that is complicated to look at full of jiggling relations.

In the same way, a VPL may initially appear complicated, but this is often a reflection of unfamiliarity rather than inherent complexity.

As with many technologies, given time and development, there's potential for something groundbreaking to emerge.

What may seem complex today could become a new standard tomorrow.

Re: Unit: A visual programming system [video]

#39

Post by bmitc » Fri, Aug 18, 2023, 9:26 AM UTC

Mali- wrote: post #36

The problems spoke for themselves over the course of the presentation. Something as simple as a counter was very complicated to look at, filling the screen with jiggling nodes. The presenter then introduces a bug while trying to decrement, and is unable to debug it.

Those aren't arguments against visual programming languages in general.

Re: Unit: A visual programming system [video]

#40

Post by samuelmtimbo » Sat, Aug 19, 2023, 1:17 PM UTC

DonaldFisk wrote: post #18

Interesting, and clearly a lot of work's gone into this (60,000 lines of Typescript), particularly the UI, which is impressive (if, sometimes, over the top). I've been developing a similar system ( http://www.fmjlang.co.uk/fmj/tutorials/TOC.html ) and it's interesting to note the similarities and differences. Similarities: code as directed graphs (less obvious in FMJ); can only connect outputs to units of compatible…

Hey, thanks for the analysis and questions!

I did check on FMJ many years ago when researching about Visual Programming Languages. I recall the very inspiring notes on the FMJ website (http://www.fmjlang.co.uk/fmj/FMJ.html).

(1) The type system is inspired by TypeScript. It has generics that are resolved when unit pins are connected to concrete types. Right now there’s no way to define new types. Hopes are that type inference alone would be good enough for a start. Likewise, new interfaces cannot be created. Only the system defined interfaces can be exposed, such as channel `CH` and media stream `ST`. That is interesting because it influences the design of machines in terms of common interfaces and protocols for inputs and outputs.

(2) The visual representation is a graph specification stored in JSON. I think JSON works well with current version control systems in terms of diff readability, but I don’t see why custom unit components couldn’t be created to show the diff in graph, visually.

(3) The unit will stop the data flow and emit an “error” event. To catch this event particularly, there’s a `catch unit.

(4) Yes, there’s a few examples of recursive units, such as a `merge sort` in the open source system. The `editor` unit can’t create them from scratch right now though… but it can be done with a meta trick…

(5) The graph is loaded and saved as a JSON. The JSON has to be read by an interpreter that will instantiate all the primitives and make all the connections. Unit specification is language agnostic, but currently the project is all written in JavaScript (works with Web and NodeJS).