“A bladeless knife with the handle missing.”
– C. C. Lichtenberg
As I’ve been implementing my little “programming language for everyone” in stages, the question has recently arisen as to whether to introduce variables early on — basically the idea of saying “I’m going to call these things by some name, and then later when I refer to that name, I will still be talking about these same things.”
At first I was resistant. After all, an assignment statement such as “x = y + 3” — a centerpiece of traditional math-oriented programming — seems very disconnected from the day-to-day experience of most people. I think it’s not so much that the concepts are so difficult, but rather that such statements deal with abstract entities that cannot be seen or directly experienced.
And yet we do have something quite like this in real life. The reason that the above quote from Lichtenberg is so delightful is that it makes us think consciously about something we all take for granted on a very deep level — the identity of objects. Consider, for example, the dog who lives in my neighbor’s apartment. This dog might change drastically through the years. He might grow from a little puppy to a huge beast, or get into a fight and lose an ear, or one day grow ill and lose half of his fur. Yet through all of these changes he’s still the same dog. In a room full of dogs, even dogs that looked very similar, he would be the only one who is him.
We deal with this concept all the time. You or I might change so drastically over time, in appearance or behavior, as to become unrecognizable. Yet we are still, unquestionably, ourselves, in a way that no other individual could ever be. These concepts of identity — the naming of things — are so fundamental to our human way of thinking that they are built directly into all natural languages, for as far back in time as anyone has been able to trace the evolution of natural languages. They are not technological aspects of humanity, but rather part of our innate biology — a product of the way the human brain has evolved to understand and generate communicative speech and gesture.
And so I’ve come to the conclusion that a programming language for everybody needs to embody the concepts of identity and assignment of identity. You need to be able to give a name to a thing or a person — or to a group of things or people. Then no matter where the named thing goes, or how much it changes, you can refer back to it later.
Speaking of names, an astute reader sent me an email pointing out that it might be too early to fix a name — even as appealing a name as “Pie” — to a project that is still so much in flux. Naming things too soon can tie you down to ideas that later turn out to be wrong. I’m going to take his advice and keep the question open for now, rather than committing to one name so soon. Although it could turn out that my problem is not so much with the word “Pie”, as with the word “commitment”. 🙂
About assignments with the equals sign – I never thought it made much sense, especially when in some languages it can be used as a comparison operator as well. I’d prefer pascals syntax over c’s for this ( := for assignments, = for comparison ), but maybe that’s just because pascal was my first language. = just doesn’t show the direction. I’d prefer <– or << or <= or some unicode character of an arrow.
How about “is”? As in “Fred is the short guy on the left.” Or “The short guy on the left is Fred.” I’ve been using “is” in my language prototype, and so far it seems very intuitive.
Hmm. What about “be” ? Imperativ / future ? Then again, any form of “to be” might be confusing because it is usually also used to express properties or states. Fred is tall. Fred is funny. Fred is dead.
Ah yes, the eternal question. To be, or not to be… 😉
If the language is designed right, we can look at the type of the thing on the other side of the “is” to figure out whether we are assigning an identity to Fred, or just refining his properties. For example, the following sequence of sentences:
Fred is the chair on the right.
Fred is red.
might describe the actions: “Call the chair on the right ‘Fred’. Now paint that chair red.”
Although I would prefer to say:
Fred is the chair on the right.
Make Fred red.
because that avoids any ambiguity. Since we are using snap-together blocks, we can restrict the syntax to things that definitely make sense within the language — such as making sure that anything to the right of “is” refers to objects, not properties.
I prefer the 1st option, because I have two problems with the 2nd one (is&make):
#1 They’re essentially interchangeable:
– “Make Fred the chair on the right.” and “Fred is red.” seem as valid. Now, of course you could restrict to only valid usage, but it doesn’t make it easier to intuitively understand and memorize. I guess that’s just one of the issues with using English words.
#2 “Make” and “is” differ:
– “is” describes a state
– “make” describes an action or a command
“be” would be more like a command, maybe like a magic spell. “Be red!” Actually, doesn’t that seem like a great way to present programming: It’s like writing a magic spell! This way you get away with the language sounding a bit strange. Abracadabra!
Programming is magic: Have a virtual world in which you need to learn programming in order to do supernatural things. If you don’t know how to code, you’re bound to the laws of nature, but if you know the magic, well then you can do all kinds of things, like making Fred red!
On the general topic of inducing kids to programming in a friendly fashion, are you aware of Microsoft Research’s project Kodu?
http://fuse.microsoft.com/kodu/
I actually haven’t played with it personally, but it looks interesting. My daughter is four now, so I suppose it won’t be long…
Yes, Kodu is wonderful. I think though that it works in another part of the space. Kodu was never intended to be a language that kids could grow up with, and use as a serious tool for doing useful work through their teen and adult years.
I’m trying to figure out whether there is a language that will create an unbroken pipeline, all the way up through the grade levels, for widespread learning and use of programming.