It's a good onramp to building a programmatic intuition, but you're correct that it very quickly gets left behind once the 'magic' is understood. If you do a quick image search for , e.g. Rhino3D Grasshopper, Blender Geometry Nodes, Vectorworks Marionette, Autodesk Dynamo, ComfyUI, you'll quickly see the implementations of the real world procedures users are crafting become unwieldy rather fast.

I can't tell you why an 80 column wall of characters is easier to reason about than a visual graph, but I assume it has something to do with the reason Mitch Hedberg does not like arrows[0]; look, a function.. let's got that way.

[0] https://youtu.be/EI1DBRz3JLk?si=DCLNkbeCGWyw-Ceu

I don't think this is for people that would just write code. Maybe you need that pressure release to get some edge cases, but for the most part, if you're using a visual programming tool, you are trying to avoid the code part for some reason.

So, I don't see that limit as something that's all that bad.

Should we call this luciana1u's law?

If BizTalk has it, why shouldn't my visual programming tool have it?

and then the evolution of the whole tool slows down as the answer for most limitations in native functions becomes "just use the 'code node' and write the function there" :)

as someone who writes code, examples 2/3 are non-intuitive

(maybe more context would help)