Ask HN: Why isn’t visual programming a bigger thing?

Re:Ask HN: Why isn’t visual programming a bigger thing? by TheOtherHobbes on Thursday May 21, 2020 @06:43AM (#23256853)

Difficult concepts can't be represented in visual form. There's a hard limit to the amount of complexity you can represent visually. On the far side of that line everything starts to look like spaghetti.

But... this can be improved with good tooling and clear abstraction layers. Some of the problems with visual systems are caused by poor navigation and representation systems. Making/breaking links and handling large systems in small windows makes for a painful level of overhead.

This also applies to text - jumping between files isn't fun - but visual representations are less dense than text, so you have to do more level and file hopping.

If someone invented a more tactile way of making/breaking links and you could develop systems on very large screens (or their VR equivalent) so you could see far more of the system at once, hybrid systems - with a visual representation of the architecture, and small-view text editing of details - might well be more productive than anything we have today.

[ Parent | on HN ]

Re:Ask HN: Why isn’t visual programming a bigger thing? by negentropicdev on Friday May 22, 2020 @02:31AM (#23269235)

I love this idea and I'm already picturing a mashup of LabVIEW class hierarchy/VI call hierarchies but it's dwarf fortress with multiple z-level view enabled and you can mousewheel up and down through the pyramid of the application architecture. I'm just lost as to how you'd relate/visualize the dynamic instances of classes/modules so that you could have a unified debugging environment, like you do with the regular block diagrams.

I've recently debugged LabVIEW code that resulted in the taskbar listing of windows names to overflow. Definitely less than optimal.

[ Parent | on HN ]