Today I am revisiting the topic of my January 21st post Learning from Children, in which I talked about the possibility of Universal Programming Literacy (UPL). But today, rather than talk about how to achieve such a thing, I’d like to talk about whether it’s a good idea at all.
It is clear that we live in a world in which, even in the most literate and computer savvy of societies, only a small percentage of the population programs computers. It is reasonable to ask the question “Is there a scenario in which pretty much everyone in society programs computers?” I don’t think it comes down to ability. Just about anybody can understand how to program, if taught the right way. I know this from first-hand experience. I think the more salient issue is utility, and therefore motivation.
One argument against UPL posits that programming is like carpentry: We all sit on chairs, yet a society only needs a relatively small percentage of its population to be able to build chairs. Some people may learn carpentry as a hobby, but it’s not necessary for your child to be able to build furniture in order to succeed in society. Therefore there is no compelling pressure from parents and communities to make sure every child learns how to be a functional carpenter.
A counter-argument in favor of UPL – and this is very hard to make in the context of most of today’s programming languages (C++, Java, Python, C#, etc) – is that programming can evolve to something more like written language: A communicative tool that helps provide the glue by which people form into communities. This has been the role served by written literacy since the Web took off in the mid ’90s: The fact that millions of people can read and write has allowed the Web to enable a grass roots kind of communication, in which communities can form themselves around common goals and interests, rather than needing to depend upon trained experts.
Those of us who program know that our skill provides us with an enormous increase in our ability to take advantage of the power of computers – the computer becomes a fantastically powerful and extremely protean servant. We are able to instruct the computer to do things for us that require millions of custom operations. For example: go off and search through millions of items, see which ones match what I want, combine them in this particular way with these other items, and bring me back the best result. Very powerful stuff indeed.
And yet, if it turns out that the number of people who would benefit from directly wielding such power is small, then programming is indeed akin to carpentry, and then there is no point in trying to promote UPL. On the other hand, if it turns out that such power can be fruitfully applied by people in such diverse fields as sociology, economics, community activism, literature, politics, music, poetry, and so on, then we’re talking about something that is more like written literacy, and then there is a reason to pursue UPL.
My current sense is that the problem is still ill-posed, because the kind of programming language that would empower most people to do the things that matter to them does not currently exist. Most existing programming languages are rather brittle and are quite focused on relatively mathematical operations. Those kinds of operations are very useful for those of us who do things like computer graphics, physics, statistical analysis, and other tasks related to mainstream computer science, but are not really useful for modeling the sorts of problems that come up when you’re looking at history, community activism, or the works of Charlotte Bronte.
A small number of special purpose programming languages are widely adopted by people who don’t think of themselves as programmers. In each case (unlike C#, Java, C++, etc), the programming environment is not brittle – mistakes don’t take down the whole system – and the visual representation of the language itself maps well to the problem being tackled. Some examples of this are Excel and similar spreadsheet languages for modeling finance problems, and Max MSP and similar visual data-flow languages for building procedural music.
My sense is that if any programming language is going to succeed in the broader arena of human endeavor, it’s going to have some important qualities in common with these special purpose languages: (i) The programming environment is very forgiving of mistakes: Whatever fool thing you choose to do, you can’t crash the program; (ii) Things are “always running”: There won’t be the sort of compile/run cycle that traditional programs rely on now. Rather, you will be making continual interventions into a world that continues to exist at all times; (iii) The program itself appears to model the problem you’re solving: In some sense, the “code” appears to be intuitively superimposed upon, or even identified with, the problem space that is being modeled (think Excel).
It could be that even with all these qualities, it simply doesn’t make sense for many millions of people to be interacting with computers by programming them – maybe programming is really carpentry and that’s that. But I think that in order to do experiments that aim to find out one way or another, we need to be developing and testing these sorts of guiding principles.