HN Explorer

Ask HN: Why has visual programming not caught on?

6 points by jshharlow ↗ HN
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...

21 comments

[ 3.0 ms ] story [ 61.4 ms ] thread
nostrademons
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.

jshharlow
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.
david927
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.

nostrademons
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.

david927
If I draw a picture, did I program? Are artists programmers? What if I try to execute that binary of a digital image? I would say: no to the first, yes to the last. I think it's a big difference: the aesthetic and basic syntax qualities of markup, the completeness of a list of invitations to a party, and executable code.

To me, HTML, CSS, XML, etc. are not code and do not have real bugs; they have design flaws and syntax flaws, just as a picture may need more red or blue. (But note that I'm not sure there's a right answer here, and I certainly respect you and your opinion.)

I also think that it's not about abstractions but better abstraction mechanisms which work to reduce complexity at any level. It may get more complex, but you can manage that complexity much more skillfully. I am absolutely confident that we can find better abstraction mechanisms.

bartonfink
GUI layout in the sense of moving around graphical elements to produce a larger, desired image is not programming.

GUI layout in the sense of creating a series of instructions for a computer to automatically create and display the same image is much closer to programming than you're making it out to be. In fact, I would say that it is programming at a higher level, as you're not producing an image - you're producing code that tells the computer how to produce that image. If that's not programming, I don't know what is.

[deleted]
(comment deleted)
extension
The same reason visual writing hasn't caught on. Our brains are wired for textual language. It's generally hard to express highly abstract ideas with just pictures.
bartonfink
The Egyptians would like to disagree with you. The Chinese, Japanese and other ideographic cultures are right behind them in line.
extension
Ideographic writing is still sequential text.
bartonfink
In the same sense that picture books are sequential text.
extension
I've never seen a visual programming system that was anything like a picture book. Rather, every one that I've seen uses some sort of graph visualized in two or occasionally three dimensions.

In contrast, every natural language that I've seen, along with every remotely successful programming language, uses a one dimensional sequence of words and/or symbols with an implicit grammatical structure. That is probably no coincidence.

CyberFonic
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.

ippisl
Doesn't the reason you use visual representations in CAD, construction , aviation and layout is to be close to the domain ? i.e. visual objects.

A second reason is that higher level languages for mechanical design hasn't been successful. my guess it's because mechanical objects are very cost sensitive, so people use low level tools, similar to embedded developers using c+asm.

On the other hand , if you look at fpga and chip design , where complexity has exploded and transistors price really plummeted , you see a move to higher and higher level textual languages, from the schematic systems used in the past.

Another interesting use case for visual languages is visual domain specific languages. metacase has some success with this. my guess is that visual languages can be much easier for domain experts to use and understand, in some cases.

hrasm
A visual language called G exists. It is forms the backbone of LabVIEW (a product of National Instruments [NI]). You could use it like any other programming language to solve problems. IMHO it is quite powerful. However, LabVIEW's real strength lies in providing an easy interface for data acquisition from cards, again by NI, specifically built for the purpose. LabVIEW is pretty much ubuquitous in university labs.

Edit: There is also Agilent VEE.

dumbphone
I like the idea of using a web-based interface for tasks that are normally done in framework code: Altering data structure/models, etc. Drupal already has this (CCK), but it's not exactly a lean/small framework, so it's not the ideal solution unless you actually need the CMS feature (the ability for non-techies to edit content on the website).

Anyway, I think a framework that includes a web-based data handling thing might be a success.

_0ffh
Because it is a crock of shite, that's why. Ask anyone who ever used an actual (general-purpose) "visual programming system" for any (nontrivial) real life task. I have extensive experience in one, and a little in another, and both suck balls. The problem is that, while the diagrams you are constructing might look fancy and intuitive to a layperson (i.e. your pointy haired boss), they do usually not help you to structure the complexity of the task at hand in any meaningful way. Usually, they make everything worse. Having said that, there is a rather big exception: Domain specific visual programming systems, if they are well designed and the problem domain lends itself to it, can be quite useful.
actionbrandon
I think this is part of it. The people who would have to write/design the visual programming system think that it is for losers and are thus not interested in working on it. Most hardcore coders I have met are quite proud of their chops and kind of brush off those who can't cut it (which is fine imo).
jdietrich
Syntax is the easy part. The hard bit is abstraction, as proved by FizzBuzz[1]. The core syntax of a language like Ruby or Python can be learned in a couple of hours. Learning to write useful, maintainable software takes years.

How do you create an intuitive, visual representation of recursion? Iteration over an array? The task isn't creating a visual representation of current programming paradigms, it's creating a whole new conceptual approach. I'm not sure that such a thing is even possible.

[1] http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-dev...