Below is how we're creating a playing field for later development of more math concepts using the idea of "math objects" and "maths an extensible type system". This is for elite academies like Phillips Andover, which uses the Litvins text in some way (not as focused on the object oriented paradigm as my stuff).
The first draft of the verbiage below was published through Python.org where we have a special interest group of longstanding (edu-sig).
Kirby Urner PSF '09
Footnote: Clifford Nelson posted some Mathematica jazz he brands "Synergetics Coordinates", has a whole song and dance about it. I'm not one of Cliff's fans and don't subscribe to his theories, so any criticisms of his work should be aimed at him, not me (I've also been critical, especially on a list called Synergeo on Yahoo!).
What do we mean by "computer language"? One could answer in terms of using text to control electronics, and that would be accurate. However there's also the goal of a philosophical logic: to express situations in the world, to mirror them for the purposes of simulation.
The veteran programmer of the late 1900s experienced a number of twists and turns in the art of computer programming. This field has evolved quickly. Early machines had to be programmed "close to the metal" meaning a deep understanding of hardware internals was needed to even begin to write code.
Today's computer languages haven't completely divorced themselves from hardware concerns, but the higher level ones are freer to concentrate on what we sometimes call "knowledge domains" such as cellular automata, molecular biology, zoology, telescopy etc.
When talking about human languages, we have something we call grammar. It helps to know the difference between a verb and an adjective, an adjective and a noun. In many of today's computer languages, nouns name objects which have attributes (like adjectives) and behaviors (like verbs).
Here's an idea of what computer code might look like:
If you've studied some mathematics, you may be used to reading "=" as "equals". You're free to keep doing that, but add the thought that "=" is an "assignment operator" and what it does is bind a name to an object.
In the above segment of code, the Ant and AntEater types are instantiated and assigned to names. These names are then operated upon using "dot notation" such that attributes get set and behaviors such as eating get invoked.
Notice that we already have a tendency to think in terms of things (a very generic statement). Think of an airport. What "things" do you suppose it would have? Runways and taxiways would define paths for the airplanes. There might be a control tower. Lots of things have come to mind already.
A single airplane has many attributes and behaviors.
We also have an ingrained concept of the more general versus the more specific. There's the generic idea of a house, animal, airport. Then we get more specific, getting to some individual instance or example of any of these types of object.
A computer language might have this same idea: there's a type of thing called a Number, and then we have individual instances of Number, such as 3, -1 or 2.12 or whatever.
Suppose you had a generic blueprint for a robot dog. You could create an instance of this blueprint at any time, and then modify the specifics to give yourself an individual dog. Each "instance" would take up its own place in memory, even though the blueprint is shared among all these instances.
Imagine a snake named Selma, maybe a cute cartoon snake. She has a sister named Bella. Creating these two snakes from the Snake template might look like this:
selma = Snake() bella = Snake()
At this point, all that differentiates these two snakes are their names. Two snake objects have been born, and assigned to names. Now we might modify each snake separately:
selma.color = 'red and brown stripes' bella.color = 'various shades of gray'
One might eat a mouse, the other might eat a cupcake:
Notice our "dot notation" has so far mostly followed these grammatical patterns:
noun = Type() noun.adjective = value noun.verb()
It maybe help to think of open-close parentheses as a "mouth". Think of emoticons like :-) or :-(). The () is clearly a mouth. A mouth eats or takes in. We call often call the things a mouth eats its "arguments".
An event such as noun = Type() is akin to the birth of a creature or instance from its generic type.
Then we make our noun do things or define its attributes, with noun.verb(arguments) or noun.adjective = value. Also, we don't just set attributes (store them), but we also get them (retrieve them).
What's important to realize about the above quick run through is we've nowhere had to discuss the internals of a computer or how it works. Writing scripts will require naming our actors and defining their behaviors, their interactions. Writing a program is a lot like scripting for theater.
We need to know how to express ourselves grammatically in a computer language. But that's the same with ordinary human languages, so this need shouldn't seem too alien or unfamiliar.
Now, the grammar suggested above is characteristic of several computer languages, but certainly not all of them. Given we're heading into a study of the Python computer language, all of the above is apropos (relevant).