🚀 go-pugleaf

[ I suggested that dataflow languages, like the UNIX pipes, are best adapted
  to visual languages ]
> I am not so sure about this.  Let's stay with the example of a Unix pipe
> "program".  This is always a one-dimensional flow of data.

Unfortunately, it isn't. I frequently want to combine data in more complex
ways, and are reduced to using temp files or makeshifts like !(shell | tee
/dev/stdout 1>&2 | ... ) | something else!

Here's a stripped down version of something recently posted to the net:

> doc=/tmp/splchk.$$
> scr=/tmp/sedscr.$$

> cat $args > $doc

> cat > $scr <<HEAD
> s/^/ /
> s/\$/ /
> HEAD

> spell $spellflags < $doc | sed -e "\
> 	s/^/s;\\\\([ 	][^a-zA-Z0-9]*\\\\)\\\\(/
> 	s/\$/\\\\)\\\\([^a-zA-Z0-9]*[ 	]\\\\);\\\\1${T1}\\\\2${T2}\\\\3;g/
> 	s/ \$//" >> $scr

> cat >> $scr <<TAIL
> s/^ //
> s/ \$//
> TAIL

> sed -f $scr $doc

> rm -f $doc $scr

Now that 'sed' at the end takes two input streams, one is a command
stream from $scr, and the other is the contents of a set of files in $doc.

Visually, this would be something like:
              .--C> cat ------v
args --> tee <           .-C> sed --> output
              `---> sed -'
Where C> means the command input of the program. Using a 2-d visual
language this sort of thing becomes easy.

> The visual programming system I have worked on, SunPict, views programs
> procedurally, mapping program statements to icons on the screen.  I
> think that this control flow visualization adds much more to the 
> understanding of programs.

That's a perfectly good format for dealing with procedural languages. As
is the conventional linear format. On the other hand, there really isn't
a good linear format for dataflow languages...
-- 
`-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>.
 'U`  --------------  +1 713 274 5180.
"vi is bad because it didn't work after I put jelly in my keyboard."
   -- Jeffrey W Percival (jwp@larry.sal.wisc.edu)