Saturday, May 21, 2005

N = N + 1

When first learning about programming, most people get confused by expressions like
N = N + 1
The origin of the confusion is easy to understand. Expressions like
N = N + 1 often occurs in a computer program dealing with mathematical concepts. And, in mathematics, the expression
N = N + 1
is just plain wrong. Ergo the confusion. To get around the confusion, some programming language introduce a different symbol for "variable assignment". Something like ":=" , or "<--" can be used for that purpose. Python uses the equality symbol for variable assignments. As a result, beginners are often presented with the baffling N = N + 1 before they have understood enough about the language to grasp quickly what is meant by that expression. I suggest that examples based on a "human language context" as opposed to a traditional "mathematical context" could be more useful to teach the meaning of variable assignment.

1. A little story

John, Pierre and Antonio are three good friends that share a house. John is originally from England, Pierre from France and Antonio from Spain.

One day, John was speaking in English to Pierre. During that conversation, John said the word "once", referring to an event that occurred a single time. Pierre translated this concept in his mind as "une_fois".

>>> once = 1
>>> une_fois = once

>>> print 'once = ', once, ' une_fois = ', une_fois
once = 1 une_fois = 1

Later that day, John was speaking in Spanish to Antonio. He mentioned his favourite number: "once" (11), made up of the same letters as the English word "once".

>>> once = 11

However, the conversation that John is having with Antonio has not changed the meaning of "une_fois" for Pierre.

>>> print 'once = ', once, ' une_fois = ', une_fois
once = 11 une_fois = 1

The various words in human languages are associated with concepts or objects that are independent of the words used to represent them. So, "une_fois" is associated with the number 1, through its association with the word "once". However, "once" is just a word, not an object. So, when "once" takes on a different value later, the concept represented by "une_fois" is unchanged.

2. The meaning of = in Python

In Python the symbol "=" associates a synonym on its left hand side to a concept on its right hand side.

synonym = concept/object

ords that are chosen as synonyms, are chosen in a context dependent way. In our later story above, names are chosen based on the "human language context". The same combination of letters can mean two different things in different languages, or even in the same language. I remember a little test a friend of mine did in grad school, showing parts of a newspaper headline to fellow classmates (all science geeks) and asking them to quickly read it aloud. The word "unionized" appeared in the headline. Now, think "labour" and "chemistry" and you will think of two different way of pronouncing this word.

Now, in the typical programming situation, "N+1" represents a mathematical concept. We can give it a (temporary) synonym of our own chosing, depending on the context...

3. Another short story

John makes a groceries shopping list, with two items: "bananas" and "pears". He then tapes it on the fridge door.

>>> groceries = ["bananas", "pears"]
>>> epicerie = groceries
>>> print groceries
['bananas', 'pears']
>>> print epicerie
['bananas', 'pears']
Later that day, Pierre walks by and notices the list too (une liste d'épicerie) which he associates with the word epicerie. Still later that day, John adds "apples" to the list on the fridge door. He notices that Antonio had already bought pears and remembers that they also need oranges. He thus scratches the item "pears" and replace it by "oranges".

>>> groceries.append("apples")
>>> print groceries
['bananas', 'pears', 'apples']

>>> groceries[1]="oranges"
>>> print groceries
['bananas', 'oranges', 'apples']

>>> print epicerie
['bananas', 'oranges', 'apples']
The list has changed throughout the day, but it remains taped to the fridge. When they think about the grocery list, both John and Pierre are referring to the same object in their own language. When that object changes, it changes for both of them in the same way.

4. Yet another short story

John makes a groceries shopping list, with two items: "bananas" and "pears". He then tapes it on the fridge door. Later that day, Pierre walks by and notices the list and decides to make his own copy.
>>> groceries = ["bananas", "pears"]
>>> epicerie = list(groceries)

Still later that day, John adds "apples" to the list on the fridge door. He notices that Antonio had already bought pears and remembers that they also need oranges. He thus scratches the item "pears" and replace it by "oranges".

>>> groceries.append("apples")
>>> groceries[1] = "oranges"
>>> print groceries
['bananas', 'oranges', 'apples']
Pierre's list, however, is unchanged.
>>> print epicerie
['bananas', 'pears']
Let's just hope that Pierre won't go out and buy pears!

5. Conclusion?

Your comments are going to provide a much better conclusion than I could write at this point!

Wednesday, May 18, 2005

News about rur-ple

Things now seem to happen all at once on the rur-ple front.

A. Judkis at the Academy of Allied Health and Science, in Neptune NJ, had decided to inflict RUR-PLE on his 10th graders. The response has been so far very positive from the students from what I hear.

Someone contacted me offering to translate RUR-PLE in Spanish. Hopefully this can be done before version 1.0 is released.

A number of bugs were introduced accidently in version 0.8.5 - mostly due to the language selection ability (English/French) that was added. These bugs never manifested themselves on my computer, but they seem to affect everyone else! I suspect it's because I have a French version of Windows. These bugs should now be fixed in version 0.8.6a.

I have a neat (I think) Tower of Hanoi solution worked out and included (undocumented) in version 0.8.6a. This version also includes a solution to the 8 queen puzzle (also undocumented).

Unfortunately, I will be on the road for 3 weeks in June, and will not have time to do significant work on RUR-PLE for a while.

Tuesday, May 10, 2005

rur-ple version 0.8.5 released

Version 0.8.5 of rur-ple has been released.
The web site has completely changed; it includes over 35 new pages.

Learning to program computer should be fun, for adults and children alike. RUR-PLE is an environment designed to help you learn computer programming using the language Python. To use RUR-PLE, you need wxPython. You can learn more about RUR-PLE or you can go to the download page.

Apprendre à programmer devrait être amusant,
que l'on soit un adulte ou un enfant.

RUR-PLE est un environnement conçu pour vous aider à apprendre la programmation informatique avec le langage Python. Pour utiliser RUR-PLE, vous aurez besoin de wxPython. Vous pouvez en apprendre davantage au sujet de RUR-PLE ou vous pouvez aller à la page de téléchargement.

(This morning, I got an invitation to talk about rur-ple at EuroPython next June. Did I dream this? ... Reality has not sunk in yet: I'm still floating above the ground. :-)

Saturday, May 07, 2005

Getting closer to version 1.0 of rur-ple

I just release version 0.8 of my project, rur-ple, on sourceforge. It looks even better than what I dreamed it would when I first started working on it:
Teaching computer programming

I do find it difficult to deal with the version number issue. On the one hand, I feel the software part has all the features I wanted (and more) working when I started this project. In that sense, it is past a version 1.0.

On the other hand, the 'ple' part in rur-ple means Python Learning Environment. I mean for this to be a 'complete' tutorial in learning about programming with Python. The lessons I have written so far only cover the use of about half the Python keywords. So, I can't bring myself to calling it version 1.0. So, I've sort of settled on adding a '0.01' to the version number for each additional keyword/programming concept I manage to introduce. However, somehow, I feel that giving a sub- 1.0 number to the version is sending the message that the software part is somehow buggy or incomplete, when it is (almost) bug-free and certainly feature complete.

On a somewhat unrelated note, I have found a solution on my own as to how to
change the language used in a wxPython-based GUI APP without having to restart the application under Windows. As a friend pointed out, by not using the common I18N starndard (gettext, .po and .mo files), it might deter people from adapting it to languages other than English and French which are currently working. However, I feel uncomfortable with what seems to be an underlying assumption about the "standard" approach.

As I understand, the standard approach is based on looking for some locale information on the user's machine. If the local language is available, then the app uses that language, otherwise it reverts to the default - usually English. But what if the user is a native Spanish speaker who has some knowledge of Italian and French, but essentially none in English. And what if translation are available in Italian, French but not in Spanish. As I understand it, the average user will be presented with an English interface, and will normally have no clue that French and Italian interfaces are available. Or, if she does, she might not know how to switch locale on her computer. (I don't ... as I never needed to myself. Can it be done easily under Windows XP - just a rhetorical question; answer not really needed :-).

The approach I use is to have the available languages in a pull down list (with flags as icons on the side) AND the language names appear in that language, i.e. English, Français, etc. (and not English, French ... or anglais, français).

This strikes me as being more sensible.

Adapting/translating a French expression: It is my own opinion, and I share it completely with myself! C'est mon opinion, et je la partage entièrement avec moi-même.