augh, blueprints can be so bad. I TAd a game design course where lots of students reached for UE. There were some students games that I just could not help debug. So spaghetti

What tools does UE give you to group / nest nodes? Can you make things that act like functions?

yes you can make functions

Ah, so it's just like what happens when people write text-based code and don't know about functions, loops, data structures, etc.

So there is a thread on the front page of hackernews about visual programming https://news.ycombinator.com/item?id=19025639

Following @Ivan Reese comment, how is it different from a beginner coding everything in one file without functions, loops, etc?

Yeah. I've never read a good critique of visual languages on the matter of beginner messes. Every argument that hammers on that "failing" completely misses the fact that there are existing solutions to the code organization problem that work well, so either (A) this particular VPL doesn't have them or (B) the programmer making the mess hasn't yet learned how to organize their code.

nice, awesome points

Thanks for that discussion, I enjoyed reading through!

So beautiful. I'll reiterate that messy node-based VPL is "obviously" messy whereas messy code is less so. Though some of these are rat's nests, many cases appear to suffer from the common problem of flattening a stack of similar elements which would appear much more natural in 3D.

I don't agree 😄 IMHO 2d node-edge diagrams are considerably more structurally constrained than text. It's counter intuitive because moving things around a canvas feels like freedom but "visual connectivity" and "spatial layout", are actually false additional constraints on the abstract thought-stuff that is programming. It is these constraints that cause hairball structures that are simple to understand in text. In the general case, node-edge diagrams of "the entire truth" of any system rarely work. Instead, you need a narrow goal of what you want to communicate and then pick and choose the relationships to show. A diagram has to be some kind of lie to be effective. 3d adds another dimension that can reduce some types of ambiguity like intersections but it's still adding false constraints i.e. line of sight and distance and the necessity that you now must move through the scene to comprehend it because our perception is still limited to a 2d projection with a touch of depth perception. IMHO where vpl goes wrong is thinking that a single visual metaphor can be the ground-truth and as versatile as text. Instead we should be thinking in terms of multiple task specific views. Think of how we design buildings, multiple views at different abstractions, different 2d projections, different content e.g. wiring diagrams, sewage diagrams, 3d renders, fly-throughs, physical models etc. Trying to do all the tasks through one visual metaphor would be brutal.

The analogy of multiple diagrams for buildings is cool @duncanawoods . Have you thought of some specific diagrams for code? Or what would mean wiring/sewage/etc for code?

The additional diagrams I get a lot of value from are call-graphs. This includes both from static analysis and run-time tracing (they can be very different in practice). I'd much prefer to work with text but when I want to understand how a function is used by different high level processes then they are vital. I have actually built a tool for this for C# that I'm kind of getting around to releasing. I would normally use doxygen to generate call-graphs but it hasn't kept pace with language features. What I also wanted was some interactivity to filter out parts of the graph and focus on what I wanted. The call-graph for a parser I was working on...

Think of how we design buildings, multiple views at different abstractions, different 2d projections, different content e.g. wiring diagrams, sewage diagrams, 3d renders, fly-throughs, physical models etc. Trying to do all the tasks through one visual metaphor would be brutal.

Yeah, this is pretty much the train I'm on. I take this sort of stuff as a given, because I work for a company that teaches industrial systems troubleshooting. I've been bathing in hydraulic schematics, process diagrams, ladder logic, and their ilk for over a decade now. It's not uncommon to come across a binder full of schematics that is >6 inches deep, many thousands of diagrams, all for one machine. Those paper artifacts are legacy — these days, we have really, really good software tools for working with fiendishly complex suites of schematics. Looking at that world, and then looking at what we call "visual" programming, just makes me laugh with sadness.

Cool @duncanawoods! please share your tool when is ready or sharing the progress would be great to see the kind of diagrams that will be available

@duncanawoods Once every blood moon, I revisit concatenative programming, which is, arguably about using 1d node-edge diagrams. 🐺

@wtaysom I think you might be on to something about messes. You are are only talking about evil messes but I think there are also "virtuous messes". A virtuous mess is much better than another evil "premature organisation". I think traditional file/text encourages premature organisation and then makes it hard to restructure your way into a better organisation. I think about virtuous messes as an Academic's study. They often have towers of papers and apparent mess... but I think that is because they are trying to discover a new organisation. If they prematurely organised all their papers into files then it would be harder to discover the new organisation they are pursuing. I think it's a bit like Marie Kondo - for refactoring, you need to pull everything out of the files into one big pile on your bed to then reorganise and cut the dead weight. A virtuous mess is a positive and necessary transition state for finding optimal organisations. I think visual tools are better for making virtuous messes!

@duncanawoods Virtuous messes! An aspect of it is that there's may not be one "true" representation. One virtue of code (or diagrams) from hell is that they are optimizing something – something different than what we we're used to. It's like having familiarity with cross-discipline tooling. Some of the things that "they" do will be abhorrent from our side of the and some will be miraculous.

Yes! Code in its raw text form feels to me like just one representation that we’re mostly adapted to, partly because we’ve been working with text for ages and partly because that’s just how we program. It still is just one particular view on a mess of entangled objects, which happens to be the most common and popular one today. We’ve grown accustomed to using spatial positioning (which line in the text file), visual hierarchy (tabs or spaces), and some other sometimes language-specific tricks (scope, functions, classes, etc.) to categorize things so we can keep some overview, and yet there are dimensions that this text view can’t be optimized for at the same time. Like for instance the mentioned call-graphs, or finding the place where a symbol is declared vs. used or vice versa. For these things, we need either different (often graphical) representations, or interactive tricks like a “jump to definition” feature in our IDE. I’m still wondering how much of our preference for text is just habit or familiarity versus text being inherently superior to other representations. After all, isn’t text rendered through a UI framework just another bunch of glyphs rasterized into textures positioned on a 2D plane following strict layout rules?

Yep @Ivan Reese mentioned flying but I'm reminded of Eric Reis talking about how IMVU added teleportation to their VR experience as a quick movement hack because implementing walking was going to be so much work but users actually preferred it to walking. There is so much more magic available to us building virtual worlds that we shouldn't take the physical constraints of our real 3d space too literally. https://www.inc.com/magazine/201110/eric-ries-usability-testing-product-development.html

@duncanawoods I wouldn't call IMVU a VR experience in modern times (maybe in the 90s when anything 3D called was called a VR experience...). This highly depends on the expectations of your audience. In virtual reality (referring to HMD based VR, which is what people mean by VR when experience in 2019 for the most part) teleportation of a specific style is standard because it universally fixes motion sickness due to locomotion (motion outside of natural motion as a result of tracked movement), and there is a strong vocal minority of users that hate it, so VR games with any kind of locomotion almost always have to have options