There is such a thing as cognitive style. And cognitive mismatch. It's possible for a given programming system to be badly mismatched to the cognitive style of its user. Asking which are better: verbal programming languages or visual ones, is pointless without asking: better for whom?
Some parameters of cognitive style are well known, like general intelligence, left or right-handedness, spatial versus categorical reasoning, and so on. One parameter which is not so well known is whether you perform best if you treat your problem domain as a collection of things to be manipulated, or actions to be performed. This is something innate and readily measurable. It pervades all areas of life, whether talking or writing English, or writing programs. Strongly "action" people do not perform well with systems designed by strongly "thing" people, and vice versa. Your cognitive style, in this regard, is the biggest single thing that's going to determine whether or not you take to a given computer tool. Now it's tempting to make the correspondences: Action -- function, verb, command, program, tool, menu etc Thing -- object, noun, data, icon, geometric shape etc and to suppose that expresses some law of nature. But I think it says far more about the history of how computers were developed, and by what sort of people, and how we were all educated and trained in the period 1920-1980. Cognitive style has been well researched since the late 1970s, when it drove the development of the WIMP interface (ALTO/Mac/Windows). Prior to that, you could say operating systems and development tools were heavily prejudiced in favour of action people. Action people tend to develop problem domains with a rich variety of actions and very few things, usually of a generic nature. Think of J, with over 100 primitives, mostly verbs, and basically just one sort of "thing", called an array. And in tacit programming, things (=nouns) disappear altogether from the problem representation. At the other end of the scale you have the original Apple desktop, designed by and for thing people, with its proliferation of things (=icons), plus a starved repertoire of (generic) actions: Select, Open, Duplicate, Drop. (NB: not even Delete: that's a Drop onto the Trashcan.) Most "visual programming" systems I've encountered are thing-based, taking their inspiration from CAD systems. Which go back a long way, to rigs adapted from WWII radar sets. I'm not convinced this is an essential feature, or merely reflects their history. Plus their stated objective of course. DreamWeaver is a visual development tool aimed precisely at graphic designers (traditionally these are thing people) who find it hard to design a good web page by coding directly in html/css. Its strength is that it suits either cognitive style by allowing you to switch reliably between text code and visual image, shoring-up the blind-spots of each. On Sun, Jan 13, 2013 at 12:12 AM, 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
