Isn't "visual programming" exactly what a whole lot of 3D artists do every single day?
Whenever I watch people using Blender it sure looks like a whole lot of visual programming to me.
We need visual programming. No, not like that
41–50 of 505 posts
Re: We need visual programming. No, not like that
#42Programming “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.
Re: We need visual programming. No, not like that
#43The "swimlane diagram" (I've not heard that term, before) looks a lot like the classic bus timing diagrams that I've used since the 1980s. I tend to use the same kind of diagram, whenever I'm illustrating a linear flow (or, more often, a set of linear flows). One of my most useful tools is OmniGraffle.
Swimlane diagrams are from the 1940s[0]. IGrafx trademarked it in 1996. They're often used to model process' that span people, roles or security boundaries [1][2][3].
Sequence-diagram participants[4], and gantt-sections[5] are sometimes used to represent the same.
[0]: https://en.wikipedia.org/wiki/Swimlane
[2]: https://www.lucidchart.com/pages/tutorial/swimlane-diagram
[3]: https://www.drawio.com/blog/swimlane-diagrams
[4]: https://mermaid.js.org/syntax/sequenceDiagram.html#participa...
Re: We need visual programming. No, not like that
#44[deleted]
Re: We need visual programming. No, not like that
#45I just want an IDE that abstracts my code just enough so that I can work with tokens, not individual characters. I spend way too much time fixing syntax and formatting when moving things around.
Re: We need visual programming. No, not like that
#46> Developers say they want "visual programming", which makes you think "oh, let's replace if and for". But nobody ever made a flow chart to read for (i in 0..10) if even?(i) print(i). I'm not convinced by this particular example. Wouldn't a visual programming language just represent the logic here as a pipeline connecting two more atomic operations: you'd have a visual representation where you pipe the (0..10) range…
I do not think what they say is that it is hard to visualise it, but that it does not offer much utility to do so. A "for" loop like that is not that complicated to understand and visualising it externally does not offer much. The examples the article gives is about more abstract and general overviews of higher level aspects of a codebase or system. Or to explain some concept that may be less intuitive or complicated. In general less about trying to be formal and rigorous, and more about being explanatory and auxiliary to the code itself.
Re: We need visual programming. No, not like that
#47TBQH, 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 eventually loses to just using a better model. And each of those visualizations is very bespoke, and 3.5 Sonnet really feels like it's on the cusp of this stuff.
That being said, I think the core idea is right: use the visuals developers already use! This will help communicate more effectively to the models, too: there's already a large corpus of those kinds of visualizations.
Re: We need visual programming. No, not like that
#48I just want an IDE that abstracts my code just enough so that I can work with tokens, not individual characters. I spend way too much time fixing syntax and formatting when moving things around.
Maybe give Cursorless a try. Although they mostly show off the voice recognition, it has a keyboard interface too.
It lets you edit with high-level commands like "swap argument a with b", or "move function x before function y".
Re: We need visual programming. No, not like that
#49I think the difficulty here is addressing: who is your target audience? Depending on that answer, you have different existing relatively succesful visual programming languages. For example, game designers have managed to make good use of Unreals' blueprints to great effect. Hobbists use Comfy UIs node language to wire up generative AI components to great effect. As far as generic computing goes, Scratch has managed t…
[post author] I agree. On many domains you can find a great mapping between some visual representation and how the developer (beginner or not) wants to think about the problem.
I personally don't see any one pictorial representation that maps to a general programming language. But if someone does find one, in the large and in the small, that'd be great!
Re: We need visual programming. No, not like that
#50The "swimlane diagram" (I've not heard that term, before) looks a lot like the classic bus timing diagrams that I've used since the 1980s. I tend to use the same kind of diagram, whenever I'm illustrating a linear flow (or, more often, a set of linear flows). One of my most useful tools is OmniGraffle.
Swimlane diagrams are from the 1940s[0]. IGrafx trademarked it in 1996. They're often used to model process' that span people, roles or security boundaries [1][2][3]. Sequence-diagram participants[4], and gantt-sections[5] are sometimes used to represent the same. [0]: https://en.wikipedia.org/wiki/Swimlane [1]: https://swimlanes.io/ [2]: https://www.lucidchart.com/pages/tutorial/swimlane-diagram [3]: https://www.dra…
another good one is https://sequencediagram.org/