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 nothing will. Fred Brooks - No Silver Bullet: Essence & Accident in Software Eng. http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf and The problem with visual programming is that you can't have more than 50 visual primitives on the screen at the same time. Peter Deutsch - "The Deutsche Limit" http://en.wikipedia.org/wiki/Deutsch_limit So, is this true? Is it perhaps easier to express detailed, abstract thoughts textually than visually? Is there some analogy between programming : visual programming and novels : graphic novels, where the latter are quicker to grasp and more visually appealing, but the former admit more detailed, abstract, and ultimately richer expression? Has anyone here had experience with visual programming? What are your thoughts? -Dan [1] "Visual Programming and Why It Sucks", Davor Babić. http://blog.davor.se/blog/2012/09/09/Visual-programming/ [2] "Can a programming language be completely visual?", Geoff Perlman http://www.realsoftwareblog.com/2011/08/can-programming-language-be-completely.html On Jan 12, 2013, at 6:55 PM, Dan Bron <[email protected]> wrote: > This was really interesting Devon. Thanks for sharing it. It led me down a > couple of rabbit holes, and one of them blew my mind: > > http://vimeo.com/36579366 > > That video is an hour. It is worth the hour. Bret Victor starts out by > stating that one of his foundational, motivating principles for working and > inventing is making it easier for creators to connect with their work, by > which he means get feedback faster. > > Then he demonstrates how that might play out in different creative > disciplines, through tools he developed for programmers (both concrete > programming like writing a video game, and abstract programming like coding a > search algorithm), for circuit designers (and how a change in medium is an > unparalleled opportunity to improve notation), for film-makers and graphic > artists (where new technologies like the iPad might make creating movies more > fluid, intuitive, exploratory, and ultimately creative). > > The video is framed in a call to action for principles-driven invention, and > ends with discussion of how some famous and effective historical figures (in > computing and otherwise) identified invisible problems, turned them into > missions, and ultimately built lives from them. > > But leaving aside the philosophical bent, if you've ever felt the > exhilaration of developing in the J (or APL) session manager, where there > rapid back-and-forth almost seemed a conversation with the interpreter, or if > you've experienced an almost playful joy when exploring a concept in the > REPL, and J's notation felt almost suggestive to you, then you'll get what > he's saying, and the demos will hook you. > > I've known many programming languages in my life, but I've abandoned most of > them, J being the outstanding exception. I now see J less as a programming > language, and more as a language; when I want to create something, my first > instinct is to turn to J, though it lacks some of the task-oriented tools I > can find easily elsewhere. Part of that is its no-fuss setup, as Devon > indicated, but another part -- the largest part -- is the immediate, fluid > feedback, and the iterative, playful, exploratory experience it engenders. > > I've often wondered how that experience can be brought to other languages, > other endeavors - and Bret demonstrates some very compelling ideas. > > -Dan > > PS: One of the reasons J is uniquely suited to this kind of REPL-based > development is that it is terse. You can express big ideas in just one line, > and then get feedback on those big ideas (that one line) immediately. Bret's > video demonstrates how you might achieve that in a more verbose, > von-Neumannish language (Javascript). I wonder what kind of development > system we could produce if we combined J's inherently immediate nature and > some of Bret's ideas! > > > On Jan 9, 2013, at 12:20 PM, Devon McCormick <[email protected]> wrote: > >> There's an interesting article referenced by Slashdot here: >> http://www.xconomy.com/san-francisco/2013/01/08/programming-literacy-done-right-its-about-the-tools/?single_page=true. >> >> The author makes the point that there's a lot of unnecessary cruft around >> most programming environments and identifies two gaps in particular: >> "No-fuss setup" and "Task-oriented tools". >> >> J could do better on the first of these - though it's getting close. >> Something like automating loading all the add-ons at installation would get >> us a bit closer. >> >> The latter gap is one we've brought up many times at NYCJUG. It's tough to >> address thoroughly with such a small community but things like some of the >> labs and packages people have worked on - like Cliff's images add-ons - are >> steps in the right direction. >> >> -- >> Devon McCormick, CFA >> ^me^ at acm. >> org is my >> preferred e-mail >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
