In Mashhuda’s comment from my blog entry the other day about universal programming literacy, she contrasts the chair made by a skilled carpenter with the pre-fab kit that the consumer buys from IKEA and assembles at home. I think this might be a misleading analogy to bring to the question of “consumer level” programming.
The major factor missing from the IKEA-assembling consumer’s experience is not technical expertise or deep knowledge of the tools of the trade, but rather any sort of design process. The IKEA chair kit is deliberately designed to avoid any design decisions on the part of the consumer. And we can argue – as Bill Buxton has, consistently and articulately – that the major hurdle to learning good programming is not the mastery of the technical tools, but rather an effective knowledge of design process.
I think a better analogy is with cooking. Millions of home cooks do a reasonable job of making good and original recipes. Often they start with a recipe that they learned from a book or neighbor, and then they iteratively refine this recipe over time, often creating something fresh and original.
To anyone who knows both programming and cooking, it is clear that both involve algorithmic thinking – the ability to produce a well defined result from a series of procedural steps. The major difference is that cooking requires direct action, whereas programming requires instructing the computer to perform actions by proxy.
When I described the UPL question to my colleague Natalie Jeremijenko, she quite sensible asked me “Why will people be doing it? What purpose will it serve them?” And I think she was exactly right. After all, Bill Buxton’s questions about design process are not primarily about the tool, but about the purpose – design begins not by picking up your tools but looking at the problem you aim to solve.
By this reasoning, the tools that allow millions of people to program in a powerful way are going to be those that allow those people to achieve goals which really matter to them. For example, very many people are motivated to create recipes and to compose original music, and in both cases many of those people become quite good at cooking or composing. The populations that can do these things well is much larger than is the population that can program.
I suspect that the reason for this is not that either creating recipes or composing music is an inherently easier task than programming, but rather that each is a communicative task, understood to be a direct way for one person to emotionally connect and bond with another. I think we are going to see a kind of programming tool effectively embraced by large parts of the population only when that tool is shown to be effective in allowing emotional connection and bonding between people.
it’s useful to distinguish between language that defines the process to create a product (recipe jargon, procedural computer languages) and language that describes the product itself (music notation, film tv and play scripts, declarative computer languages).
procedural language, except in the most trivial cases, or in the most expert minds, generally fails to convey the thing itself. reading a recipe is not akin to looking at, smelling or tasting the final product. whereas a musical score (with some training) can be “heard” on sight. and a well-crafted screenplay can transport a minimally literate reader (trust me on this) into a film.
all of which goes a long way to suggest that procedural programming languages are doubly handicapped as a communication medium. for one PLs describe process. and moreover, as you observe, the process is not human per se but a mathematical and mechanical proxy.
BUT musical notation is a proxy for the sound an instrument would make (and thus the instrument is analogous to a computer).
so perhaps if our computers were more like musical instruments and our programming languages more like scores AND the feedback between the score (the program code) and the instrument (the program itself) were visceral, emotional, and real time (i think of your facial expression applet as an example) perhaps then we could begin to talk about programming as a communication medium.
My answer for “why” is that we’re surrounded by machines and we need to know how to talk to them. As machines get more complicated, we need to get away from every machine having its own interface (how many ways have you seen to set a digital clock?) but standardize on a computer language that will let people say what they need to say.