Programming without math, part 9

There are concepts described easily in normal English conversation that are rather more difficult to describe in computer languages. For example, when we say “the block is red”, or “the block is blue”, it is understood that “red” and “blue” are mutually exclusive. Therefore if we say “the block is red and blue” then it is understood that the block must be painted with some pattern — red in some places and blue in others. Yet if we say “the block is tall and blue”, there is no such conflict — the block can indeed be blue all over, no matter how tall or short it is.

This works because we’ve come to the conversation with an elaborate set of prior understandings. We know the concept of color, and therefore that red and blue must be mutually exclusive. In programming parlance, we are bringing with us a rich library of properties that everyone in the conversation shares.

Generally speaking, programmers have a much clunkier way to describe the same thing. Concepts like “red is the ‘color’, of something” tend to be spelled out right there in the statement, rather than relying too much on prior understandings of what everything means. So, for example, we would explicitly say “the color of the block is blue”, rather than just “the block is blue”. I think this is one of the things that makes programming difficult for most people to learn. They are expecting the computer to know what they mean when they say something is red, rather than having to explicitly say that the color of that thing is red.

So it seems that if we want to teach programming in a natural way to people who aren’t already versed in the ways of programming, we need to build in some of these intuitive ideas about properties. We need to be able to say things like “red, blue, yellow and green are colors”, and then be free to ignore the word “color” entirely when we say something is red or blue.

Another thing we do in natural language, without really thinking about it, is to casually talk about entire sets of things. We don’t really think about this, we just do it. When you say “pick up a box and hand it to me”, you are really talking about a number of things. You are asking somebody to consider the entire set of boxes — presumably the boxes that are in reach of the other person. Then you are asking that person to randomly choose one of those boxes. It feels like you were just talking about one object, but in fact you were doing something much more complex. It doesn’t seem complex only because we are so used to these sorts of constructions — we are so good at them — that they completely fly below our radar.

So the question comes up: how much of that kind of implicit wisdom should be built into programming languages to make those languages accessible to everyone? I’d be curious to know if anyone has any thoughts about this.