Lambda the Ultimate

This can be true. I use a programming language called Max, which is entirely graphical, kind of like Flogo. If a Max program (or "patch" in Max-speak) gets beyond a certain complexity, it can be very difficult to figure out what is going on.

In the case of Flogo, I suspect that programs would not be so complex that children would encounter the kinds of difficulty that I have with Max. I think the graphical nature would help children understand the flow of programs better; so it's a kind of trade-off.

(I wonder if there is a middle-point. I remember in a linguistics class we discussed pictographs vs. alphabets, and my professor mentioned that pictographs offer a form of compression, because one symbol maps onto one concept, and so would take less time to "parse." Compare this to a concept in an alphabet -using language, where it's representation may be composed of several symbols, and so the time required to "parse" or understand the concept is longer.

Would a programming language which used pictographs "scale" better than a graphical one, while still having good readability ?)

In Max, a user creates "patches" which are composed of objects linked by "patch cords" that represent the flow of data. Each object has inlets which respond to specific messages, and outlets, which (naturally) send messages. Patches may also contain subpatches, or "abstractions," which are basically generic patches, or really, functions.

In addition to the Mac version, there is a clone written in Java by some researchers at IRCAM called JMax, and Miller has a similar program called Pd, which runs on IRIX, Windows NT and Linux.

As I said, Max has a large user base in the computer music community, and there are several books about it or which have examples written using it. The Computer Music Journal published a good critique of it a few years ago, but unfortunately, I can't find the citation for it.

Related to that is a comparison of ideographic vs. phonetic writing systems. The following page offers a very good summary.
http://www.sf.airnet.ne.jp/~ts/japanese/message/jpnDwlWNqXkDwjfGuYF.html
In particular,

"It's a common misunderstanding that ideograms are obsolete and phonograms are modern. In fact, linguists have proven that a human being can read ideograms faster than phonograms if trained to read. The disadvantage of ideograms is their difficulty to learn, but the fact that developed nations such as Japan and Taiwan have a very low illiteracy rate indicates it is not so hard to learn kanji as you might think, if good education is available. The reason why most people in the world don't use ideograms is that it needs hundreds of years to build a writing system based on ideograms."

Please note that although ideograms are more expressive, they are also more difficult to learn, requiring extensive training. Compare that with a current trend to aim "visual" languages at children and lay people and "textual" languages at professionals. In reality, it's visual languages that require professional training to master! Musical and electric circuit notations corroborate that point.

What I find complicated is the way widgets (call the ideograms) are spread across the visual field, with arbitrary lines connecting them. This requires much more effort to parse than linear (or at most two dimensional) program text.

Notice that musical notation, for example, is based on a fixed organisational principle.

APL uses ideograms. Their usefulness may be dabated, but clearly this is not the same thing as diagrams of the sort you find in Flogo.

As for visual manipulation, ERWin has been driving nuts the last few days. The problem is that the connecting lines of the relationship are incredibly hard to get right for a proper display when the number of connections gets high. The auto layout of the software always wants to revert back to the original choice and ignore any input you want to give it.

OTOH, the PCAD systems that laid out the connections for multi-layer circuit boards was quite good. In that case, however, the optimization was intended to reduce the length of the connections and minimize the interference. Wasn't really designed to be understood in a visual sense.

I'm afraid it is far more complex than it appears. Musical notation rules go far beyond a mere placement of notes on staff lines. What is not so obvious is spacing of symbols; angle of a beam; beaming of notes; ordering symbols with respect to the presence of neighboring symbols; ensuring precedence among symbols with respect to the notehead when depicting slurs, accents, markers; adding rests and repeat symbols. Spacing/justification seems like a secondary attribute -- however to a trained musician it means a great deal. Correctly-sized and justified symbols tell deeper logical connections between parts of music. These connections are lost when music is converted to a MIDI sequence. These secondary attributes, the _context_ is what makes visual notation so expressive -- and so difficult to master.

As paper [5] says,

"Most music published today is still laid out by hand; while computers may be used, decisions about music-symbol placement are made by people. Much research remains to be done into computational methods of encoding the myriad rules of music notation. ... The science of music processing lags far behind text processing because of the complex and idiosyncratic nature of music notation. Horizontal spacing is one complex aspect of music notation. While text justification is well understood, music justification is more difficult because note placement must emphasize temporal relationships in the music [sic!]. [That relationship is highly nonlinear, and may require global optimization over the entire page]. The difficulties of rule-based approaches to music spacing are discussed, and an algorithmic alternative is presented. The final music spacing is defined as a combination of two preliminary spacings: a textual spacing computed from character widths and a durational spacing computed from note lengths."

Ideograms may be easier for trained mind to read, but I would think that they are harder to write on a computer because the characters aren't available on a standard keyboard.

Therefore, ideograms are entered using a dictionary method, which is well described in
http://www.suse.de/~mfabian/suse-cjk/input.html

Their usefulness may be dabated, but clearly this is not the same thing as diagrams of the sort you find in Flogo.

I must concede. I guess I was looking for a pretext to rant about visual languages and their (mis)use.

References:

[1] Managing Music in Orchestras Pierfrancesco Bellini, Fabrizio Fioravanti, and Paolo Nesi IEEE Computer, September 1999, pp. 26-34

and references therein:

[2]. T. Ross, Teach Yourself: The Art of Music Engraving, Hansen Books, Miami, Fla., 1987.

[3] G. Heussenstamm, The Norton Manual of Music Notation, Norton & Co., New York, 1987.

[4] J.S. Gourlay, "A Language for Music Printing," Comm. ACM, May 1986, pp. 388-401.

[5] D. Blostein and L. Haken, "Justification of Printed Music," Comm. ACM, Mar. 1991, pp. 88-99.

Visual languages are interesting. I don't see how they can take the place of textual programming languages any time soon, but I guess that if you are interested in languages (and I guess most of use are), you can't fail to be interested in visual languages and notations.