181–190 of 505 posts
- Visualizing logic: I don't find it useful most of the time.
- Visualizing "metadata": Yes please.
By metadata I mean, visualizing inferred types, file/class members outline, dependencies, lints etc. Some of this visualizations are added directly to the text editor.
Earlier quoted context omitted.
My experience is that the software engineers at game companies generally hate the visual programming tools. They want to work with code. It's the game designers who (sometimes) like using visual tools.
Some are bad but Blueprints is great. Main issue is they don't always play nice with text based coding tools.
Developers all have lots of (different) opinions about editors, but they're fortunately seperated from the language they choose. People can work together on TypeScript usong Emacs, VSCode, Zed etc and it all gels.
The second someone starts with "to use this language you have to use this editor" the bar is sooo high for developers not getting their backs up.
It would be immense to have a visual way of programming that was language agnostic, but you'd need a seriously intense protocol to make that possible.
It does make me think of things like Smalltalk and Visual Basic that where designed to support multiple approaches. Interesting how that research avenue has drifted off recently.
Far more important is instant feedback and that’s getting worse all the time: with lisp, smalltalk, Delphi, forth things were instant. With typescript or rust etc, if the project is larger than hello world, the feedback is well, far from instant. Bret victor talked about feedback, not necessarily visual programming and for some reason we are making things worse instead of better. When I show a Common Lisp dev session…
Eventually they did the same thing you can do in common lisp: Add so much metaprogramming that doublechecks invariants, it might as well be a compiled language.
If (if!) you can extract the diagram (or better the graphviz representation of the diagram) from the code, then you immediately have a test that says “hang on you chnaged the code so it no longer reflects the agreed diagram - that seems like a test fail to me”
This is not to dismiss the article - it’s fantastic and I want all of those capabilities now. It’s just to emphasise (as the article does) that in almost no cases is this visual first - it’s code first
I am surprised I have not seen LabView mentioned in this thread. It is arguably one of the most popular visual programming languages after Excel and I absolutely hate it. It has all the downsides of visual programming that the author mentions. The visual aspect of it makes it so hard to understand the flow of control. There is no clear left to right or top to bottom way of chronologically reading a program.
I still have to find somebody who worked with LabView that does not hate it. It is a total abomination.
In banking, Camunda is increadibly popular. You model state changes visually. The model - the diagram with boxes and arrows - IS the code. And then the boxes can have additional code logic in them. It's a giant pain to work in and debug. But the execs love it because they want to see the diagrams.
Know of any open source equivalents to this?
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.
I would vouch a different take, visual programming makes it quite clear the mess of programs some people create when they don't follow modular programming. Complex flows can be packaged into functions and modules representations, instead of dummping everything into a single screen.