And one of the things that is disturbingly true about most novices on computers is that about 2 pages of program is the maximum they can handle. They like to spread it out, use their visual field as an extension of their short term memory
–Alan Kay From Doing With Images Makes Symbols
A few thoughts on this phenomenon.
A denser, more concise, less “English like” programming language would counter-intuitivly be easier for novices to use, if it let them keep their project below the 2-page limit.
Does this limit increase with more and bigger displays?
Do graphical programming language change anything? It seems like they might “scale” better on a very large display. But in my (albeit limited) experience they are much less compact then textual source code. And it’s not clear to me they support abstraction as well.
As someone who learned to program with graphical programming environments (I know, weird), and is now using Obj-C for my projects, I can definitely say for myself that using graphical, node based systems really helped me understand modular, oo principles of ‘good’ coding, and also let me fit a larger picture of the code base into my head (literally, “picture”). They definitively support abstractions (most support wrapping up re-usable graphs of nodes into macros or ‘sub patches’), so you can make your own meta nodes out of sets of normal nodes that do specific things you wish to re-use, like typical functions or routines.
Its also odd because the graphical flow/event model of most of these graphical languages has been very helpful to understand recursion (designing feedback systems are something that node based languages excel at), so I think they are great candidates for discussing and teaching basic principles of programming.
While graphical languages may be less compact, each node typically has a *lot* of functionality built in to it. So complex node based programs can be quite ‘short’, and easy to understand. Unfortunately that sometimes means you don’t know exactly what is going on under the hood in each node – they are a black box; which is one of the reasons I moved to Obj-C/Cocoa.
In any event, from my personal experience, using node based languages was very helpful to make me into a programmer, and also very rewarding, as you could build complex behavior quickly, experiment, and not have to worry about too many stupid syntax errors. For beginners its great, you get hooked, and are not dissuaded with the complexities of learning text based languages which imo, have a higher learning curve.
2 cents :)
Comment by vade — April 15, 2009 @ 1:44 pm
vade,
What language(s) did you use?
Do you have any recommendations for a good introductory graphical language?
I’d like to spend some time actually getting familiar with one. Beyond dabbling in Quartz Composer I haven’t used a graphical language to build anything.
Thanks for sharing your experience, it’s very interesting.
Comment by Vincent Gable — April 15, 2009 @ 2:16 pm
Hi Vincent,
Quartz Composer is kind of a weird beast, because it started out actually as a VJ application (ie, performing video in realtime) called PixelShox and was bought out by Apple and basically now used as a ‘secondary’ language to Cocoa, ie: make a few small Quartz Composer compositions and load them within a larger, Obj-C application that passes in the logic. You dont really “build apps” in Quartz Composer in and of itself.
I started out using Max/MSP/Jitter, by Cycling 74, which is really a multimedia toolkit but you can do a lot of “general purpose” programming within it. Its probably the defacto standard for ‘full’ (?) graphical programming environments. Its also a very weird beast. Its event driven, uses node position as a factor in ordering events (ie, when you have one node output to two other nodes, which one gets the even first? answer: the node that is furthest to the top and right relative to all others).
You could also check out PD, or Pure Data, which is an Open Source cousin to Max/MSP, and is thus a bit more… eccentric. Both run native on OS X.
Most of the node based interfaces I’ve seen are more for 3D/graphics/design/compositing/visual effects software, like Shake, Autodesk Smoke/Flame an friends, Soft Image XSI Ice, Nuke, (amusing software names eh?), I think Blender even has it now. They deal more with ‘signal flow’ and can let you build interesting compositions that layer based approaches really don’t work to well with.
One of the things that node based languages don’t handle well, from my experience, is complex, deep switch/if/else style flow control. The nodes/patch-coords get messy, and you see more of a tangle than a real picture of the logic. And god forbid you have to add an additional case to your nodes, re-arranging them can be nightmare-ish.
Yes I love nodes based languages :)
Comment by vade — April 15, 2009 @ 4:21 pm