tough-to-explain Python

[norseman]

Bearophile wrote:
> kj, as Piet van Oostrum as said, that's the difference between mutable
> an immutable. It comes from the procedural nature of Python, and
> probably an explanation of such topic can't be avoided if you want to
> learn/teach Python.
...(snip)
> 
> See you later,
> bearophile

==========================Perhaps because it is the way I learned or the 
way I "naturally" approach programming, or maybe the way one influences 
the other, but at any rate I think "newbies" to programming should first 
learn a few basic concepts (if/then, for, while, do and other loops and 
other control constructs) and then be forced to deal with the computer 
on it's own terms. Assembly. Once the student learns what the computer 
already knows, that the whole thing is just bits and the combination of 
them determines it's responses, it then becomes easier to present 
'idealistic' concepts and their implementations.  With the knowledge and 
'mental picture' of the computer's nature the rest of the ideas for 
programming have a tendency to drift in the direction of reality and the 
underlying needs to fulfill the 'better' and/or 'easier' languages. 
Having both the knowledge of the 'full capabilities' of a computer and 
the experience of a formalized language the student can, or should, 
learn/compare the trade offs of each.  By understanding the computer (I 
at least) grasp the basics of a new language quite quickly. No, I don't 
become a guru overnight, if at all, but I do have the advantage in 
deciding if a given language is appropriate for a given job with very 
little research.

The more I delve into OOP the more I liken an 'object' to a box. A box 
with a shipping manifest.

There are big boxes,
little boxes,
squat boxes and so on.

A box can contain corn flakes,
bullets, raisins, rice, burlap, silk, motorcycle(s), soap and more.

The manifest describes contents.
The manifest is there but the description(s) change with content (type).
The descriptions always use one or more of the basics like: color, 
count, dimension and so forth.

Just like an OOP object.

A box can contain things of all sorts, including references to the 
contents of other box(es). A box can even be a virtual of another (the 
global concept).  The return statement, in this context, means hauling 
the contents of the box (and/or its manifest) back to (wherever) and 
disposing of the current box (a local).

Just like an OOP object.


It is easier to visualize a box and it's use than a non described blob.
Abstracts are never precise -  hence the evolution of the word.


The one thing a teacher will always fail is the same as anyone else who 
tries to adequately describe a pretty sunset to a person born totally 
blind. No point(s) of reference.



Time for me to sign off.  To all those that helped me when I needed it -

I thank you very much.

Food for thought: your watch (clock) does not tell time.
The watch (clock) only mimics one movement of the earth.
ie... 3 dimensions are still static, the 4th is movement.


Steve