Python as first language (Re: static variables?)

Terry Reedy tjreedy at udel.edu
Wed Nov 20 16:51:36 EST 2002


"Hung Jung Lu" <hungjunglu at yahoo.com> wrote in message
news:8ef9bea6.0211201119.2f846d0c at posting.google.com...

>Sorry for digressing, but this reminds me of an old debate on whether
>Python is suitable as the first language to teach.

> Well, the thing is that Python works with "name binding". And the
> concepts of name spaces, name binding, objects, mutability, etc. are
> just a bit non-obvious.

I somewhat disagree.  An object is something with identify, generic
type, and specific value.  Binding names to objects is common in
everyday life.  We also name slots and refer to objects by the name of
the slot where currently located, but this is probably less common and
less obvious.  For instance, your parents (I presume) bound the name
Hung Jung to you shortly after birth.  On the other hand, if you stay
in a hotel, you might be 'the person in Room 223'.  If you moved up
several floors, you could be 'the person in Room 1287'.  In school,
you might have been either 'Hung Jung' or 'the child in row 4 seat 3',
but I suspect you would have been more comfortable with the former.

Namespace is just a fancy (but specific) word for context.  A
particular name may be bound to different objects in different
contexts.  For instance, 'John' may be bound to one child in one
classroom and another child in another.  So namespaces are a way to
reuse names within an information processing language.

How is mutability non-obvious?  You change location.  You get sick and
then healthy (I hope).  You learn.  We put things into containers and
take them out.  On the other hand, words are fixed sequences of
letters.  But sealed containers may be less obvious.

> Once a person understands these things, or if
> a person knows about pointers, hashmaps and memory structure,
> everything becomes clear.

One of the things I like about Python as an *information* processing
language is that it is *not* defined in terms of computer hardware.
This means that humans can interprete Python code *without* mentally
simulating a computer.  This should mean that people should be able to
learn Python without learning a machine model.  I would think that
this should make Python easier to learn than languages which are
defined in terms of a machine.

> After many years in the Python world and having seen so many
debates,
> I still have to say that Python is not good as the first programming
> language to teach.

Not as good as what?  Assembler?  Basic?  Fortran? C?, C++?,
CommonLisp? ... Whether or not Python is suitable as a first language
(your original question), which I would expect it to be by some
criterion until evidence showed otherwise, is quite different from 'is
it as good (or even the best)?', which would be much toughter to show.

Rather than debate, I would like see evidence.  A real trial would pit
Python against one or more specific other languages.  There would need
to be a language-neutral test.  Students should be randomly assigned
to classes after being disabused of preconceptions and prejudices.
There would need to be multiple teachers so the trial was not just a
trial of teaching ability.  Such trials are now routine in medicine
but not yet in pedegogy.

>Maybe it's just
> me, but I have been horrified by programmers writing a few lines of
> code, without realizing their few lines of code can actually have
> severe impact on the RAM or the harddrive.

Impact on the RAM?  Are you talking about merely filling things up
with data (easily reversible) or something possibly more damaging,
like thrashing a drive for hours on end?  Or erasing unbacked data?
Certainly, people should not learn to open a file (open() or file())
or access the os (os.system()) without also being taught the possible
dangers.  But this is true for any language and nothing, that I can
see, to do with Python as a first language.  In any case, one of the
nice things about learning to program is that sandbox programs
restricted to keyboard input, RAM memory, and screen output really
cannot really hurt anything (on a single user system).  Quite
different from, for instance, learning to drive.


> I still feel more
> comfortable if the new generation of programmers starts with a
> language closer to the machine level, where one can kind of "feel"
the
> bits and bytes. Just my 2 cents. :)

Having starting with 1620 assembler (and paper tape input) and later
'graduated' to Fortran and punched cards, I think people might better
start by learning about functions and algorithms with an modern
interactive language like Python.

> Hung Jung

Terry J. Reedy





More information about the Python-list mailing list