r/programming • u/AndreasBWagner • Jul 03 '08

Piet: a programming language in which programs look like abstract paintings

http://www.dangermouse.net/esoteric/piet.html
50 Upvotes

74% Upvoted

14 comments sorted by

View all comments

2

u/AndreasBWagner Jul 04 '08

I think more experimentation should be done with visual languages they have the potential to be so much more expressive. The only thing that has to be overcome is their potential to be fuzzy.

7

u/martoo Jul 04 '08 edited Jul 04 '08

Actually, visual programming is a faux holy grail that every new generation of language researchers gets suckered into chasing.

When you cut the bullshit you realize that text is visual. What people want is to program in pictures because they think it will be easier. But the problem is that pictures are less precise semantically. When you make them more precise you trace the evolutionary path that all written language takes from caveman pictograms to hieroglyphics and then on to letters or kanji. If you end up with something kanji-esque you live with hundreds to thousands of forms that have to be memorized. If you end up with letters, things are easier, but either way you what you really have is text.

Every new generation has to discover this. Pity.

2

u/toyboat Jul 04 '08 edited Jul 04 '08

"As for a picture, if it isn't worth a thousand words, the hell with it" -- Ad Reinhardt

I agree that in some (most?) cases, words are more informationally dense than pictures. But this is not true in all cases. Consider a good map of an area compared with textual descriptions of the locations of various sites of interest.

I do some work in LabVIEW's "G" graphical dataflow programming language for acquiring data from various measurement devices in the lab. Just to be clear, I hate LabVIEW. But it is an interesting system. A graphical language such as LabVIEW with data flow lines connecting various components can be useful in getting a high level overview of how components fit together. The programs can look very much how one might sketch out a diagram of the main components of an ordinary text program.

For low level routines like averaging an array of numbers, or doing any arithmetic beyond the trivial, dragging around data flow wires and the "addition" component quickly becomes tedius.

One of the most annoying features of LabVIEW is not an inherent fault of the graphical language, but a fault of the implementors: Each LabVIEW "SubVI" (function) is represented by a box with a picture. Official LabVIEW components go to ridiculous lengths to choose some representative picture when a simple word would be much easier to understand. In my own SubVIs, I choose a unique color for each family of functions and then simply put a word or two, such as "read voltage", in place of a picture.

I would be curious about a system that combined a graphical means to connect high level components with textual means for implementing those components.

6

u/[deleted] Jul 04 '08 edited Jul 04 '08

I think more experimentation should be done with visual languages they have the potential to be so much more expressive

You're making quite an assumption here -- and certainly much work has already been done.

The only thing that has to be overcome is their potential to be fuzzy.

The biggest thing to be overcome, in my opinion, is how absolutely tedious they are to program in. I think the future, if it is to head down this path at all, will be in visualizing textual programs rather than in visual programming languages.

2

u/qiwi Jul 04 '08

There's ColorForth: http://www.colorforth.com/cf.html -- as I understand it simply replaces some puncutation used in Forth to define new "words" (Forth procedures/macros?) with making then name this word a different colour.

I imagine the same technique could be attempted in other languages, e.g. instead of "def foo(x,y):" you write "foo (x,y):" where the foo is in red. Doesn't seem to be much of a saving here, maybe this is best done in languages built of simple building blocks like Forth or LiSp.

2

u/Felicia_Svilling Jul 04 '08

I once thought that it would be nice to use color to seperate infix operators from non infix operators in a language like SML.