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
