guy keren wrote: >On Sun, 4 Dec 2005, Amit Aronovitch wrote: > > > >>Rereading my essay, I think I begin to understand where the "mutable - >>immutable" comments come from >>(You see - it was even useful to ME ;-) ) >> >> > >if you simply let the link i sent you sink in - you'll see part of the >light. > > If you mean the Fredrik Lundh link, it sunk in the minute I saw it - most of it explains in a simple and clear way the things I've been explaining over and over to people while helping them fix bugs (endless variations of the examples in the wiki ref). That's why I was so excited when you said you were gonna use it for lesson 3.
It does not say anything about mutability. Only says something like "some objects you can change, some not". This is almost a null statement. Only thing to learn from is thinking why he put this statement there in the first place - most probably because a lot of people coming from other languages confuse assigning names to objects with changing their contents (hence my Eddie=Teddy example). >i will still insist on using the name variables, because i want my pupils >to be able to quickly switch to new programming languages in the future, >and not have a fixation about "how things were in python, and why it >doesn't work in C". by not telling them there are other things, i will >only create confusion in the long-run. > > No problems there (I even said something like "exact choice of words does not really matter" in my long blurb). What I'm trying to say is that to me at least it seems much better to explain python variables (i.e. names) from scratch (based on real-world meaning of the word "name", which is really close to python names). With that alone you can already write simple programs. After that, you might choose to go on about computer's memory storing numbers, representing objects, and using (named) reserved areas in memory as variables. This should seem much less confusing after you had already written a program or two. As opposed, if you explain how variables work in other languages (harder concept IMO - involves computer's memory and encoding objects as numbers), then let them believe for a while it's like that in python, then when you get to the point where it does not work like expected, do some more abstract explanations to explain python names using the "common variable" concept, well - I think this way you work harder, and the end result is programmers more likely to make bugs such as those I mention in my wiki ref. Note that I'm not suggesting that you did it this way or the other - I *don't know* what you actually said, nor what your exact plan for the future is (I got clues both ways, and I imagine your way is most likely some third option I can't see right now). The important thing about all these arguments is not to convince you one way or the other (though I might try anyway), but to better understand how you think about that. After all, if we want to write useful slides - they better match what's being tought in the course. >eventually, they have to realize that what is important is not how you >call something, but rather what it does. > > >> If we stick to "examples should only use code that does useful things" >>(one of the best tips I recently learned from you :-) ), you'll only be >>able to see any difference between the two variable models if your >>objects are mutable. List is the first multable type in this course, so >>nowyour comments make more sense to me. >> >> > >if you judge what i write without looking at the entire course, then >you'll miss the point. unlike my pupils, i expect you to see the big >picture all the time ;) > >and by the way, i am going to teach about about changing lists - >programming is very limited if you don't change objects. i can show you my >checkers game, in which i take advantage of this feature (and which is >what led me to figure out this references issue in python, in the first >place). > > > I never imagined you'd want to avoid changing stuff. Lists are intended to be changed (otherwise tuples would be enough) It's Just that the word "immutable" automaticly makes me think about dict keys and hash functions (the only place where it's important that the object *can't* change). Had you said something like "changing the objects to demonstrate references", it might not have seemed comlpletely incomprehensible to me. It's the actual changing of the object that counts (not whether or not the language allows you to do so), and it only counts because it makes the difference demonstratable (which is, of course, very important). Misunderstandings are all about choice of words...
