Yes - I think the notion of thinking visually is sometimes oversold. My favorite example is to imagine how hard it would be to convey the meaning of something very abstract like the First Amendment of the US Constitution only through pictures.
I gave a talk a few years ago contrasting visual with symbolic explanation: www.jsoftware.com/jwiki/DevonMcCormick/VisualVsSymbolicUnderstanding . I remember when I first understood - from APL's clear, consistent idea of arrays - how easy it is to deal with high-dimensional arrays based on the simple notion that the shape is a vector. On Sat, Jan 12, 2013 at 7:12 PM, Dan Bron <[email protected]> wrote: > It's also worth pointing out that it's not too hard to diff/merge a couple > of text based programs, but it's really hard to diff/merge a couple of > visual programs. > > Not sure of that's just a matter of the right technology (e.g. > distinguishing cosmetic changes, like moving a box a couple pixels left, vs > significant changes, like adding a new arrow) or whether it's an intrinsic > problem, like the visual-complexity-at-scale thing. But anyway, at the > moment, it makes version control more complicated. > > Anyway, I'll stop spamming the list now, but I'm interested in comments > from others. > > -Dan > > Please excuse typos; composed on a handheld device. > > On Jan 12, 2013, at 7:01 PM, Dan Bron <[email protected]> wrote: > > > The other rabbit hole this led me down, though it was less mind-blowing > than the video I just posted, is relevant to my line of work, and I'd like > to get some of your (Forum members') thoughts on it. Here's the quote that > caught my eye: > > > > Note that neither spreadsheets, nor Victor's examples, attempt to hide > logic > > creation behind a point-and-click interface. > > > > Purely visual programming is a red herring, and history is littered > with the > > corpses of products that have attempted to offer programming without > code. > > > > I'm in software sales. One feature of the product I sell is a > visual-programming tool (the concept being the platform I sell provides > both high developer productivity, though the RAD tool, and high > performance, through the merits of the underlying execution engine). In > parallel to that VP tool, we also provide the ability to code systems > directly in a normal text-based programming language (or Java, at the > client's discretion). > > > > Despite offering both development options, on equal footing, and despite > the inherent attraction of "visual programming", one pattern that has > emerged is that my clients overwhelmingly choose to develop in the > text-based programming language. Not due to any specific gap in the visual > programming tool (though like all products it could always be improved), > but seemingly because of the limitations inherent in visual programming > itself. Specifically, what I've found among numerous clients is that > prototypes, or high-level systems, are easy to knock together in the VP > tool, but it doesn't scale to the more detailed descriptions required of > real-life systems. Once you get beyond a handful of modules > (bubbles/boxes) and relations (lines/arrows), the visual complexity > explodes, and it becomes impossible to understand the program. It becomes > the visual equivalent of spaghetti code. It's like there's a limit to the > expressiveness of visual programming itself. > > > > Some of the links in the article you cited ([1-2]), and some quick > independent research, seems to support this view: > > > > A favourite subject for Ph.D. dissertations in software engineering is > > graphical, or visual programming. [.] Nothing even convincing, much > > less exciting, has yet emerged from such efforts. I am persuaded that > > n > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
