Live data from Hacker News

Ask HN: Why has visual programming not caught on?

news.ycombinator.com

1–10 of 22 posts

Ask HN: Why has visual programming not caught on?

#1
It seems like the concept of visual based programming (think visual basic, or drag/drop components that make code...) keeps on reappearing, do other hacker news visitors ever think it will truly succeed? It always seems to be limited imho, but the idea never seems to die, wondering what others think...

Re: Ask HN: Why has visual programming not caught on?

#2
It already has succeeded in one very limited area: GUI component layout. People use XCode/Netbeans Matisse/DreamWeaver all the time to build their UIs.

It fails in other areas because code is remarkably info-dense, and if you split that out into individual components, it takes a huge amount of screen space and visual manipulation for even simple subroutines. I encourage you to take a simple function and draw out the parse tree for it. It's surprisingly large, with lots of different node types all strung together in unusual ways. Think about how much people complain about the parentheses in Lisp; now imagine that each set of parentheses is a box on screen.

Re: Ask HN: Why has visual programming not caught on?

#5

It already has succeeded in one very limited area: GUI component layout. People use XCode/Netbeans Matisse/DreamWeaver all the time to build their UIs. It fails in other areas because code is remarkably info-dense, and if you split that out into individual components, it takes a huge amount of screen space and visual manipulation for even simple subroutines. I encourage you to take a simple function and draw out the…

Agreed, for GUI component areas it seems it has been pretty successful (I'm assuming anything complex in a GUI would also not be manageable though?). Just from some limited experience it seems a lot of "enterprise" products try to go this route. It seems like the amount of time to program the same logic, vs the complexity in the GUI would actually not be worth the benefit. But I guess the initial 5 minute demo that is shown makes it look really shiny, until u start adding complexity, and then it falls apart.

Re: Ask HN: Why has visual programming not caught on?

#8

It already has succeeded in one very limited area: GUI component layout. People use XCode/Netbeans Matisse/DreamWeaver all the time to build their UIs. It fails in other areas because code is remarkably info-dense, and if you split that out into individual components, it takes a huge amount of screen space and visual manipulation for even simple subroutines. I encourage you to take a simple function and draw out the…

GUI layout is not programming; it's GUI layout. (Or, more concretely: it's specifying a dataset.)

When software construction is finally "solved", visual representations and interfaces will be common. Our current mechanisms are simply too crude, lacking sufficient methods of abstraction, to work well. In fact, they do the opposite and point out what deep flaws exist in the current state of the art.

Re: Ask HN: Why has visual programming not caught on?

#9
We find visual based programming in the form of CAD used in construction, aviation, semiconductors, etc. They are big complex programs and, of course, expensive. If you can use visual tools to layout billions of transistors, then you could use it to write programs. But ... the techniques for moving between levels of abstraction in software haven't been understood yet. Systems like Scratch and Alice provide visual programming, but quickly become tedious for all but the simplest programs because they don't allow us to introduce multiple levels of abstraction. The CAD systems used for semiconductor design encompass hundreds of different views, each for addressing specific engineering issues.

There is quite a lot of research going on with visual programming, but the return on effort in most cases is most discouraging.

Re: Ask HN: Why has visual programming not caught on?

#10
post #8

It already has succeeded in one very limited area: GUI component layout. People use XCode/Netbeans Matisse/DreamWeaver all the time to build their UIs. It fails in other areas because code is remarkably info-dense, and if you split that out into individual components, it takes a huge amount of screen space and visual manipulation for even simple subroutines. I encourage you to take a simple function and draw out the…

GUI layout is not programming; it's GUI layout. (Or, more concretely: it's specifying a dataset.) When software construction is finally "solved", visual representations and interfaces will be common. Our current mechanisms are simply too crude, lacking sufficient methods of abstraction, to work well. In fact, they do the opposite and point out what deep flaws exist in the current state of the art.

HTML, CSS, XML, SQL, JSON, YAML, and other configuration languages are also not programming; they're specifying a dataset. I can basically guarantee that any large project will have large quantities of them, though, and that code will have bugs.

For that matter, Lisp is not programming; it's specifying a dataset. Except, well, it actually is programming, because you can execute that dataset. When you push it far enough, the distinction between code and data disappears.

This is probably an indication that software construction will never be "solved": once an acceptable representation has been found for one level of complexity, someone will quickly build on that and take it to the next level of complexity, and then the abstractions will once again prove inadequate.

Post reply on HN