3 ms·

It is surely only a matter of time until someone says 'yes, but node based editors are crap, you should do everything in code'. This has been discussed ad nause

It is surely only a matter of time until someone says 'yes, but node based editors are crap, you should do everything in code'. This has been discussed ad nauseum in HN, so I have tried to summarise the arguments here: https://successfulsoftware.net/2024/01/16/visual-vs-text-based-programming-which-is-better/ https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...

nylonstrung 10mo ago
I actually like node based editors but LLMs are the nail in the coffin. Visual programming just doesn't make sense in a world where "low-code" users can safely be assumed to be using llms
- hermitcrab 10mo ago
  I expect I can drag and drop nodes to solve a problem faster than you can vibe-code a solution. Plus a node-based solution is likely to be more maintainable if your aren't a coder.
- Closi 10mo ago
  Let's see! I'm actually working on a node-based programming LLM paradigm for an app I'm building. The idea is that you can write the 'nodes' in plain english rather than pre-written blocks, and then the arrows indicate the flow but don't need to absolutely encode everything (closer to a flow chart). The process of writing the flow chart helps define and document the business logic, and the flows are totally clear because everything is encoded into a state machine.
  - hermitcrab 10mo ago
    I am unconvinced that natural language is the best way to describe a data transformation problem.
    - Closi 10mo ago
      My personal sense is business logic which involves processes with lots of steps rather than data transformation. I’m unconvinced that code is the best way to describe business logic, so here we are! :) (Code is probably the best way to encode business logic, but most users can’t read it or edit it, which makes it bad)
      - tommica 10mo ago
        Good luck with your project. It is a tough problem you're solving, but hopefully your idea has wings.
        Closi 10mo ago
        Thanks! It's in a very narrow domain (Handset UI flows in Warehouse Management Systems) so i'm hoping that helps, but it's very domain specific and certainly not anything mainstream.
- rao-v 10mo ago
  In a world where node based editors and code are also equivalent to LLMs, it's not super clear to me that the future will not be nicely visualized and understandable nodes (generated by the LLM to explain things to me and to get guidence) kept in sync with the codebase.
Towaway69 10mo ago
Having spent a log of time with visual programming and having also loved yahoo pipes, for me, it's time to find a new paradigm. Last year, I came up with Breadboard Programming[1] which is visual programming using Node-RED but with a different perspective, that of a breadboard[2]. The point is take another perspective on programming and to find new parallels to how electronics are created using breadboards. Breadboarding is prototyping but with the intention of throwing everything away or iterating by simply copying and pasting the entire code base and then throwing it away. The difference to typical software prototyping is that the prototype can easily be copied and iterated on. Normally prototypes mutate into the final product and then remain those mutated monsters that we were going to refactor before they went into production. [1]: https://blog.openmindmap.org/blog/breadboard-programming https://blog.openmindmap.org/blog/breadboard-programming [2]: https://en.wikipedia.org/wiki/Breadboard https://en.wikipedia.org/wiki/Breadboard
- Bjartr 10mo ago
  Seems to me that breadboard coding would be a like a spreadsheet where dependencies between cells are visible at a glance and could be "rewired" in a way that's easier than hand editing the formula text
  - Towaway69 10mo ago
    Definitely not :) i would definitely avoid drawing parallels to spreadsheets rather parallels to the electronics. I explicitly draw parallels to wires because of the relation to flow based programming.
rendaw 10mo ago
I'm not sure if I've ever seen a rigorous comparison between visual and text based editing before, and I'm really interested. I disagree with some of your points: - Higher level abstractions - I don't think that's a usage of high level abstraction I'm familiar with, or else it's not true. You can have very very high level abstractions in text code, you can have very low level abstractions in visual programming (max msp). This also goes for the point about optimization in text languages. - Less hidden state - this really depends on the visual programming language. The geometry node editor in Blender has tons of hidden state - what are the inputs to your program, what are the outputs, how is it applied, etc. - Less configuration - I have no idea, but my guess is you're thinking of something like Rust where library A uses image type X and library B uses image type Y and you need to write code to convert between X and Y yourself. I don't think this is inherent to visual programming - it's just a consequence of having a large, complex ecosystem with independently evolving parts. - No syntax to remember - There's still syntax, it's just visual syntax. What does this squiggle mean? What does this color mean? What about this box around things? And unlike text, where you can just write what you see, even if you know what something is with visual programming you might not know how to replicate it (which menu button, what conditions are required, what selection do I have to make, etc), google it, etc. - Looping and recursion - This is a failing point in visual programming languages I'm familiar with, but I don't think there's anything stopping a visual programming language from offering functions, looping, and recursion. - Optimization - I touched on this above, but higher level abstraction makes _more_ opportunity for compilers to optimize. Specifically, in visual programming languages, there's no inherent concept of a "sequence" of calculations as there are in imperative languages, so compilers can freely parallelize. Then: errors and run-time feedback - yes, this is true of most visual programming languages and is super great. It's equally true for many non-visual programming languages (e.g. rust). The point about discoverability is good, and I agree. Just knowing what you can do in a programming language is very hard (the first steps). Generally in visual programming languages all the parameters are shown right there on the screen. Here are my extra advantages to visual programming languages: - I think it's good to make a distinction between control flow graphs and data flow graphs. IMO representing state machines in text based languages is pretty bad and understanding complex call flows etc can be very difficult. Most visual programming languages are purely data flow, but I think a control flow graph programming language would be very good at this. - Another advantage of visual programming languages is you don't need to come up with names in order to reuse values. Having to name things isn't a joke, and seeing lines and arrows is easier to grok then trying to 1. understand what a complex name means (and maybe forcing yourself to ignore it if the name is bad) and 2. remembering that name so you can mentally connect uses. That said, there's no need to force these to be mutually exclusive. You could mix them (allow text within the graph, or refer to the graph from text, allow making some files graphs or some text, etc), or even freely convert between them (luna lang, which appears to be thoroughly dead atm but here's some remnants: https://github.com/Luna-Tensorflow/luna https://github.com/Luna-Tensorflow/luna).

nylonstrung 10mo ago

I actually like node based editors but LLMs are the nail in the coffin. Visual programming just doesn't make sense in a world where "low-code" users can safely be assumed to be using llms

hermitcrab 10mo ago
I expect I can drag and drop nodes to solve a problem faster than you can vibe-code a solution. Plus a node-based solution is likely to be more maintainable if your aren't a coder.
Closi 10mo ago
Let's see! I'm actually working on a node-based programming LLM paradigm for an app I'm building. The idea is that you can write the 'nodes' in plain english rather than pre-written blocks, and then the arrows indicate the flow but don't need to absolutely encode everything (closer to a flow chart). The process of writing the flow chart helps define and document the business logic, and the flows are totally clear because everything is encoded into a state machine.
- hermitcrab 10mo ago
  I am unconvinced that natural language is the best way to describe a data transformation problem.
  - Closi 10mo ago
    My personal sense is business logic which involves processes with lots of steps rather than data transformation. I’m unconvinced that code is the best way to describe business logic, so here we are! :) (Code is probably the best way to encode business logic, but most users can’t read it or edit it, which makes it bad)
    - tommica 10mo ago
      Good luck with your project. It is a tough problem you're solving, but hopefully your idea has wings.
      - Closi 10mo ago
        Thanks! It's in a very narrow domain (Handset UI flows in Warehouse Management Systems) so i'm hoping that helps, but it's very domain specific and certainly not anything mainstream.
rao-v 10mo ago
In a world where node based editors and code are also equivalent to LLMs, it's not super clear to me that the future will not be nicely visualized and understandable nodes (generated by the LLM to explain things to me and to get guidence) kept in sync with the codebase.

Towaway69 10mo ago

Having spent a log of time with visual programming and having also loved yahoo pipes, for me, it's time to find a new paradigm. Last year, I came up with Breadboard Programming[1] which is visual programming using Node-RED but with a different perspective, that of a breadboard[2]. The point is take another perspective on programming and to find new parallels to how electronics are created using breadboards. Breadboarding is prototyping but with the intention of throwing everything away or iterating by simply copying and pasting the entire code base and then throwing it away. The difference to typical software prototyping is that the prototype can easily be copied and iterated on. Normally prototypes mutate into the final product and then remain those mutated monsters that we were going to refactor before they went into production. [1]: https://blog.openmindmap.org/blog/breadboard-programming https://blog.openmindmap.org/blog/breadboard-programming [2]: https://en.wikipedia.org/wiki/Breadboard https://en.wikipedia.org/wiki/Breadboard

Bjartr 10mo ago
Seems to me that breadboard coding would be a like a spreadsheet where dependencies between cells are visible at a glance and could be "rewired" in a way that's easier than hand editing the formula text
- Towaway69 10mo ago
  Definitely not :) i would definitely avoid drawing parallels to spreadsheets rather parallels to the electronics. I explicitly draw parallels to wires because of the relation to flow based programming.

rendaw 10mo ago

I'm not sure if I've ever seen a rigorous comparison between visual and text based editing before, and I'm really interested. I disagree with some of your points: - Higher level abstractions - I don't think that's a usage of high level abstraction I'm familiar with, or else it's not true. You can have very very high level abstractions in text code, you can have very low level abstractions in visual programming (max msp). This also goes for the point about optimization in text languages. - Less hidden state - this really depends on the visual programming language. The geometry node editor in Blender has tons of hidden state - what are the inputs to your program, what are the outputs, how is it applied, etc. - Less configuration - I have no idea, but my guess is you're thinking of something like Rust where library A uses image type X and library B uses image type Y and you need to write code to convert between X and Y yourself. I don't think this is inherent to visual programming - it's just a consequence of having a large, complex ecosystem with independently evolving parts. - No syntax to remember - There's still syntax, it's just visual syntax. What does this squiggle mean? What does this color mean? What about this box around things? And unlike text, where you can just write what you see, even if you know what something is with visual programming you might not know how to replicate it (which menu button, what conditions are required, what selection do I have to make, etc), google it, etc. - Looping and recursion - This is a failing point in visual programming languages I'm familiar with, but I don't think there's anything stopping a visual programming language from offering functions, looping, and recursion. - Optimization - I touched on this above, but higher level abstraction makes _more_ opportunity for compilers to optimize. Specifically, in visual programming languages, there's no inherent concept of a "sequence" of calculations as there are in imperative languages, so compilers can freely parallelize. Then: errors and run-time feedback - yes, this is true of most visual programming languages and is super great. It's equally true for many non-visual programming languages (e.g. rust). The point about discoverability is good, and I agree. Just knowing what you can do in a programming language is very hard (the first steps). Generally in visual programming languages all the parameters are shown right there on the screen. Here are my extra advantages to visual programming languages: - I think it's good to make a distinction between control flow graphs and data flow graphs. IMO representing state machines in text based languages is pretty bad and understanding complex call flows etc can be very difficult. Most visual programming languages are purely data flow, but I think a control flow graph programming language would be very good at this. - Another advantage of visual programming languages is you don't need to come up with names in order to reuse values. Having to name things isn't a joke, and seeing lines and arrows is easier to grok then trying to 1. understand what a complex name means (and maybe forcing yourself to ignore it if the name is bad) and 2. remembering that name so you can mentally connect uses. That said, there's no need to force these to be mutually exclusive. You could mix them (allow text within the graph, or refer to the graph from text, allow making some files graphs or some text, etc), or even freely convert between them (luna lang, which appears to be thoroughly dead atm but here's some remnants: https://github.com/Luna-Tensorflow/luna https://github.com/Luna-Tensorflow/luna).