Lambda the Ultimate

I want the code to be available, if I want it.

It seems like thinking about textual code helps clarify and fix language designs. You must direct your attentions to things like scope, interfaces, sperate compilation, reusability etc.

All this does not mean that tools can't be helpful. We hard some discussion recently on XSLT tools. These can help you concentrate on the lok&feel of your otuput, but the end-result is an XSLT file you can continue to work on.

>However, when you jump to visual programming, it
>seems that many want to promote the compilation
>process to a state of magic.

Wouldn't tieing the semantics of the visual programming model tightly to an underlying functional programming language solve this problem?

This seems to be the idea behind "events" and "behaviors" in Fran (Haskell). Haskell's Fudgets uses similar declarative functional ideas to tie GUI widgets to the underlying functional language.

I don't know of any visual languages built on top of these GUI systems though.

the assertion seems to rest on the understanding that humans can take in an awful lot of information in parallel, visually, in the form of a full field-of-view, whereas taking in a stream of text requires scanning it serially, across the page.

unfortunately, most of what I see people doing with computers is not reading one another's code (much as we might like this) but writing their own, and when writing I hate to say we have no particularly good bulk parallel interface for dumping our ideas into pictures. we cannot "project" what we're thinking into a picture, or any form really other than gesture or vocalization, which is implicitly serialized.

it's sad, but all I can see in these "visual" programming systems is a failure to realize that a mouse, light pen, or similar "drawing" sort of interface is exactly as serial, and often significantly slower and clunkier, than a keyboard or a voice-input system.

I don't think anybody around here is making this claim

some of what he's talking about is valid, albeit presented in an unorthodox manner. e.g. his enthusiasm for "declarative knowledge" closely matches the taste of many programmers to make their work largely side-effect-free and evaluation-order-independent, or at very least to program in a "data-driven" fashion. likewise his interest in "system imagery" closely matches the good programmer's taste for a few well-thought common module interfaces in a system, to make it amenable to quick reconfiguration and aggregation.

but that's all the substance I can see in his article. people have been pushing mouse-driven "visual object" editors as replacements for keyboard-driven languages for a long time, and the unfortunate fact that keeps surfacing is that language is the domain of most human expression, and keys offer better language input than mice.

>the assertion seems to rest on the understanding that humans can >take in an awful lot of information in parallel, visually, in the >form of a full field-of-view, whereas taking in a stream of text >requires scanning it serially, across the page.

I would question the value of rendering the *procedural* visually, but *complex declarative structures* as found in Prolog, or the *complex feature structures* of unification-based programming languages like HPSG (computational linguistics) or LIFE (Ait-Kaci) or PROFIT almost *have to be rendered visually to be comprehensible*.

Here's some 2D diagrams of feature structures: http://www.ags.uni-sb.de/~konrad/fs.gif
http://hpsg.stanford.edu/hpsg.html

The Lingo grammar of English (Stanford HPSG) which attempts to cover a significant fraction of English has a very complex declarative structure. It has a small set of grammatical rules and a very large lexicon of feature structures: http://lingo.stanford.edu/

Feature structures are difficult to read in horizontal streams of text across the page because you can embed feature structures in feature structures to an arbitrary depth. Although pretty-printed s-expressions might just get you there, the extra dimension you get in a 2D diagram makes the inclusion relation between feature structures much clearer.

Sometimes you literally need a "big picture" to get a handle on how a large complex system is put together (cf UML, linked list data structure diagrams in any textbook, finite state diagrams).

Jon Fernquest

I'm just questioning the need to input anything "visually"; where "visual input" oddly always seems to mean "with a mouse". I consider text the superior "visual input tool" for most tasks; only things with an obvious spatial metaphor (such as adjusting one's field of view, making a drawing, "feeling around" an undocumented tool, or arbitrarily selecting a piece of information from within a window) seem to benefit much from mice.

the author of this article, for instance, is advocating a form of component system assembly based on connecting boxes together with lines, in a freeform canvas widget (a la DX or PD). My experiences with this sort of programming is that it's often significantly more work than learning a (small) connection language (say TCL or bourne shell) and typing in the connections you want: you spend all your time shifting the "objects" around, to present a comfortable arrangement on the canvas, and dragging your mouse back and forth, hovering over "connection points" on the objects, etc. moreover, the spatial metaphor has the potential to break down entirely if you ever want to do higher order assembly tasks; it has to be very carefully designed to maintain expressiveness in the face of nested structures.

the upside is that you are, in some sense, forcing yourself to produce an "intuitive" visualization of your program while you're editing it; but I'm not convinced that visualization isn't best done retroactively, or at least offline from the editing process.