Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need visual programming. No, not like that

blog.sbensu.com

Post reply on HN
Print view View original

71–80 of 505 posts

Re: We need visual programming. No, not like that

#71

Post by astromaniak »

LeonB wrote: post #42

Programming “via” Visualization — doesn’t scale. Great for demos. Good in limited places. Visualizations “of” a Program — quite useful. Note there lots of different ways to visualize the same program to emphasise / omit different details. The map is not the territory, all models are wrong etc.

It works and even scales up in some cases.

For example having models of capacitor and resistor you can put them together in schematic. Which in turn can be a part of the bigger design. Then test it in simulator. That's how Simplorer works. Alternatively you can write the code in VHDL or Modelica. But visual is quicker, easier, and more reliable.

Obviously it works well for UI, was used for decades now.

As for the rest,... there are visual programmers for robots, mostly for kids.

Re: We need visual programming. No, not like that

#72

Post by sbensu »

jayd16 wrote: post #68

Anyone who mentions visual scripting without mentioning the game industry just hasn't done enough research at all. Its actually a really elegant way to handle transforming data. Look up Unreal blueprints, shader graphs, procedural model generation in blender or Houdini. Visual programming is already here and quite popular.

[post author] I am familiar with those and have used a couple. There are similar examples in music, where visual programming dominates.

The implied audience of this post (not clear) is people writing business applications, web dev, etc. The examples are picked to reflect what could be useful to those developers. In other words, all the examples you mentioned are great but they are not how a "software engineer in a software company" does their job.

Re: We need visual programming. No, not like that

#74

Post by yantrams »

The screenshot appears to be from https://unit.tools Came across it recently on twitter and loved how it looked. After going through the features list, I was compelled to try it seeing how much thought and effort went into it. The site’s been offline mostly unfortunately though ;/

Re: We need visual programming. No, not like that

#75

Post by sbensu »

twelvechairs wrote: post #20

Most of this isn't visual "programming" just good explanatory diagrams. I think it gets to a core issue which is a dichotomy between: - trying to understand existing programs - for which visuals are wanted by most but they usually need concious input to be their best - programming (creating new code) itself - where the efficiency of the keyboard (with its 1d input that goes straight to spaghetti code) has never been…

You are right. The diagrams are used as explanations not as the source of the program. But wouldn't it be neat if when you sketch out the state transition in a diagram (how I think about the state transitions), _that diagram_ was the source of truth for the program?

That is the implied point: let's go to places where we already draw diagrams and check if we can elevate them into the program

Re: We need visual programming. No, not like that

#76

Post by RogerL »

hackit2 wrote: post #13
jampekka wrote: post #2

The fundamental problem in visual programming is that it limits you to geometry (practically to 2D euclidian space). Most non-trivial programming problems are spaghetti by nature in such spaces.

Mapping to a plane doesn't help you understand how state changes occur over time, or what is the over-all state of the state-machine is. The only time I've seen visual programming work is when the state is immutable. How-ever it requires a major paradigm shift how one design, develop and test their programs.

it's pretty basic topology - embedding versus immersion. you cannot embed anything but the simplest software in a 2d plane. you end up having to endlessly try to structure things to minimize line crossings, make multiple diagrams of the same code to capture different aspects of it, or otherwise perform perversions just so it fits on a page.

And I live through this. most of my early career was DoD related in the early '90s, when things like functional analysis was all the rage. endless pages of circles and lines which were more confusing than helpful, and certainly didn't actually capture what the software had to do. Bever again.

Re: We need visual programming. No, not like that

#77

Post by padolsey »

jayd16 wrote: post #68

Anyone who mentions visual scripting without mentioning the game industry just hasn't done enough research at all. Its actually a really elegant way to handle transforming data. Look up Unreal blueprints, shader graphs, procedural model generation in blender or Houdini. Visual programming is already here and quite popular.

I've been using ComfyUI recently to manage complex image diffusion workflows, and I had no idea it was inherited from much older shader editors and vfx. It's a shame we can end up using a tool for years without knowing anything about its predecessors.

Re: We need visual programming. No, not like that

#79

Post by felixgallo »

sbensu wrote: post #72
jayd16 wrote: post #68

Anyone who mentions visual scripting without mentioning the game industry just hasn't done enough research at all. Its actually a really elegant way to handle transforming data. Look up Unreal blueprints, shader graphs, procedural model generation in blender or Houdini. Visual programming is already here and quite popular.

[post author] I am familiar with those and have used a couple. There are similar examples in music, where visual programming dominates. The implied audience of this post (not clear) is people writing business applications, web dev, etc. The examples are picked to reflect what could be useful to those developers. In other words, all the examples you mentioned are great but they are not how a "software engineer in a so…

game developers are definitely software engineers in software companies.

Re: We need visual programming. No, not like that

#80

Post by viraptor »

reissbaker wrote: post #47

TBQH, I think developing bespoke visualization-to-code compilers for lots of different visualizations will probably lose to multimodal coding LLMs within the next year. Claude 3.5 Sonnet is already very good with text prompting — I'd expect another year of model releases to basically solve turning visualizations, diagrams, etc into workable code. The bitter lesson of ML is that doing lots of bespoke things per-domain…

I use both scripting and models to generate diagrams and I think there's space for some simple balance. Basically there will be things we repeat often enough, where we want a fast, detailed, repeatable solution. And there will be one-offs you will ask for and if it's wrong, you'll fix be hand.

There's space for both and we'll probably migrate the best ideas both ways. (can't wait for a local fine-tune which can do ad-hoc diagrams with a pleasant layout in excalidraw format) I don't think either way is going away soon.

Post reply on HN