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.

2 Responses to “Programming without math, part 9”

  1. Ashley says:

    My understanding of AI and related research topics isn’t particularly deep, so forgive me if I’m saying something inane… But by saying ‘how much’ aren’t we blithely ignoring years of research into natural language processing? Is it reasonable to think that we can define a limit – unless it be the same limit that NLP currently occupies?

    Or perhaps I’m thinking far too grandly. There is no need for the programming engine to be able to correct our grammar; it’s still a machine made to carry out instructions – not to improve upon them.

    I guess I don’t have a good answer to your question. But I did just think of another interesting question: If there were a programming engine that had some knowledge of such ‘properties’, to what extent would the engineers have to consider cultural variability, or language differences? Can we build one programming engine, based on Western ‘sensibilities’ and the English language and assume it can be ported to every other culture and language? Or should we look to commonalities between cultures and languages to help define exactly what those properties should be? For example (and to make use of some sweeping generalizations), people in Scandinavia likely have a very different conception of ‘tall’ from people in Japan

  2. Andras Kanegson says:

    We need a School House Rock for programming. Seriously.

Leave a Reply