Aardappel and visual programming

Wouter van Oortmerssen's thesis on Aardappel is a pretty fascinating read, and I like some of the concepts behind visual programming, but is it practical? is there any way VPL's will ever catch on?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Oh boy.

Perhaps I'm dense, but a funky syntax coloring IDE for Prolog is nice. Though personally, I probably wouldn't want one.

Q seems to show otherwise

I found the visual syntax of Aardappel an insuperable barrier to even playing around with it, never mind using it seriously (pictures are not my strong point) and was planning to reimplement it using the verbal syntax used in the paper.

Then I discovered Q, which is a very similar dynamically-typed eager generalized term-rewriting language (though without the Linda aspects so far), which seems to be way more successful. The fairly straightforward non-visual syntax has probably been essential in gaining Q mindshare.

Here's an elegant bit of Q for Newton's algorithm:

newton DX DY F          = until (satis DY F) (improve DX F);
satis DY F X            = abs (F X) < DY;
improve DX F X          = X - F X / derive DX F X;
derive DX F X           = (F (X+DX) - F X) / DX;

You can't win..

I have long ago concluded that it's almost impossible to win against textual languages, and I even say so in my thesis I think. But that doesn't mean you shouldn't try. Certain things about graphical Aardappel are certainly new and done better than any visual programming before it, even if it doesn't yet solve the "visual programming problem".

Some of my current "work in progress" language designs try to do VPL in a much better way than Aardappel, time will tell if they are practical.

improvements

Were you to improve on Aardappel and come up with a visual method of programming that was actually... useful for production, more than a toy language, what would you change? How would it work? I've been trying to wrap my head around visual programming and how it might work but havent really been able to come up with a better way.

improvements

while the field of visual programming seems to be littered with experiments that never really make the leap to 'production' there are a few exceptions (eg, labView, max/msp and puredata, prograph). curiously, these languages seem to be used more extensivly by people who often don't consider themselves 'programmers' and generally looked on with mild distaste by those who do.

Many of the problems involved in both developing and using visual languages stem from the disjoint ways of thinking abstractly about (or with) a textually described process, and diagrams or graphic representations. As far as i am aware, there has been relativly little research into how visual representations, or abstractions can be built up into the sort of complexity seen in decent sized textual codebases, while retaining the comprehensibilty offered by small scale visual programmes.

for further reading, a quite comprehensive bibliography can be found at http://web.engr.oregonstate.edu/~burnett/vpl.html

C2 wiki discussion

This is discussed at some length (well, it is C2) on the GraphicalProgramming and GraphicalProgrammingLanguage pages.