Teaching python (programming) to children
Brian Elmegaard
in the special Python issue of Linux Journal last year Guido explained
one of the perspectives of the future was children sitting in class
writing python code for a lot of different applications.
I think that Python may be very well suited for this because it is
easy to get going with the language compared to other languages
(AFAICS).
However, in order to program you need to be able to write. And out of
the English-speaking world, learning English will be one obstacle
delaying the learning of programming.
So, any comments are appreciated, especially on: Are there good reasons
for advocating python being a language one could teach children
programming with and are there perspectives in translating python to many
different languages in order to facilitate this, or will children not be
ready for learning programming before they have learnt English after all?
--
Brian (remove the sport for mail)
http://www.rk-speed.dk http://fiduso.dk http://sunsite.auc.dk/dk-tug
\TeX, tak.
Paul Rubin
> So, any comments are appreciated, especially on: Are there good reasons
> for advocating python being a language one could teach children
> programming with and are there perspectives in translating python to many
> different languages in order to facilitate this, or will children not be
> ready for learning programming before they have learnt English after all?
The best-known attempts to teach children programming have been with
the Logo language. See the book Mindstorms, by Seymour Papert. He
has another book out called "The Children's Machine: Rethinking School
in the Age of the Computer", but I haven't seen it yet.
Nomad
<br...@rk-speed-rugby.dk> wrote:
>However, in order to program you need to be able to write. And out of
>the English-speaking world, learning English will be one obstacle
>delaying the learning of programming.
>
>So, any comments are appreciated, especially on: Are there good reasons
>for advocating python being a language one could teach children
>programming with and are there perspectives in translating python to many
>different languages in order to facilitate this, or will children not be
>ready for learning programming before they have learnt English after all?
IMHO, python would be one of (if not _the_) best language to teach
beginning programming - not just children, but as you mention, there
is the difficulty with the "englishness" of the language (or almost
any other programming language).
However, from my viewpoint, and the way I perceive the the world
going, children that will have access to PC's are reasonably likely to
have already learnt some english, if not quite enough to start out.
But the question I have to ask, is what age are we talking about here?
IMHO, even if many young children have learnt enough english to
program in any language, may not be intellectually mature enough to be
able to think in the abstract manner that will be required for all but
the most basic algorithms and design patterns. I that case I would
greatly prefer a child to learn when it is ready rather than see it
taught in lower (pre-high or pre-secondary) schools.
just my R0.02
--
Nomad
Wondering of the vast emptyness of the 'net
in search of something cool.
Guido Stepken
I have had great success in making children (12-15) having fun programming
python .... before the were only interested in playing gameboy...with
pygame, SLT they are now trying to programm a simple game for windows ....
For Mindstroms there is a python module in work.....
have fun, Guido Stepken
Hung Jung Lu
> IMHO, python would be one of (if not _the_) best language to teach
> beginning programming - not just children, but as you mention, there
> is the difficulty with the "englishness" of the language (or almost
> any other programming language).
I have my doubts about Python being the first programming language to
teach. I see all too many newbies running into the problem of
namespaces. How do you explain to them that "from xyz import *" is a
bad thing, if they don't even understand what's going on behind the
scene? Also, how in the world can beginners understand what a hash
table mean? Are we going to tell them something like: "oh well, think
of Python dictionary as a magic black box, you'll understand it later
when you take a course in C/C++"?
Python seems very friendly, at first sight. But unless you really
understand the dictionary and namespace (and name binding) mechanisms
behind it, you'll run into surprises in no time. And at that moment,
there is simply no way that it could be explained in easy terms to
beginners, when they don't understand things like pointers,
references, memory stack and heap, hash tables.
I do believe Python should be part of a programmer's school
curriculum, but I really doubt it can be a good first language to
learn, unless some technicality questions are addressed properly.
Or is there a good way of teaching to make it less traumatic for
beginners to grasp the concepts of dictionary, name spaces, assignment
by reference? It is just really really annoying that every single
newbie has to be explained on these issues, and many of them end up
without understanding it. I can't imagine teachers having a good time
at these issues. I mean, it's OK to make students understand these
Python issues, but the time required is not negligible, and the
knowledge gained is limited in scope: these peculiarities are very
Python specific. And it's doubly frustrating when after spending all
the time, the students end up without understanding it. What can you
do? It's not the fault of the average students or the average
teachers, when the language itself has a non-trivial component that's
hard to explain/understand.
Hung Jung
DeepBlue
"Hung Jung Lu" <hungj...@yahoo.com> wrote in message
news:8ef9bea6.01110...@posting.google.com...
> Python seems very friendly, at first sight. But unless you really
> understand the dictionary and namespace (and name binding) mechanisms
> behind it, you'll run into surprises in no time. And at that moment,
> there is simply no way that it could be explained in easy terms to
> beginners, when they don't understand things like pointers,
> references, memory stack and heap, hash tables.
>
inherent difficulty in grasping such concepts, but the teaching methodology.
Also you are underestimating students.
Teaching methodology is what counts. I have seen some smart people with
grasp of certain 'difficult' concepts but are such failed instructors who
made a mess in the way they explain things. What you need is the equivalent
of John Archibald Wheeler and Richard Feynman in Physics. Believe me: if
someone can explain Space Time Physics (Wheeler) and Quantum Electrodynamics
(Feynman) in an everyday language that everyone can actually follow and
understand; you are going to find talented people who can explain name
spaces to beginners. After all, on a 'diffiiculty' ladder, what is a name
space concept to the concept of a Riemann non-Euclidean Geometry or a 4D
Minkowskian Space Time vector!
DeepBlue
Skip Montanaro
Hung> I have my doubts about Python being the first programming language
Hung> to teach. I see all too many newbies running into the problem of
Hung> namespaces. How do you explain to them that "from xyz import *" is
Hung> a bad thing, if they don't even understand what's going on behind
Hung> the scene? Also, how in the world can beginners understand what a
Hung> hash table mean? Are we going to tell them something like: "oh
Hung> well, think of Python dictionary as a magic black box, you'll
Hung> understand it later when you take a course in C/C++"?
I think the assumption is that you don't give them everything at once, and
you can simply avoid teaching them the "bad" stuff like "from m import *".
Regarding dictionaries, I would tell them, "Think of a Python dictionary as
a regular dictionary. You look up a 'word' and it gives you the
'definition' of that word." The correspondence is good enough to get them
going I think.
--
Skip Montanaro (sk...@pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/
Michael Hudson
[schnipp]
> Or is there a good way of teaching to make it less traumatic for
> beginners to grasp the concepts of dictionary, name spaces, assignment
> by reference?
I suspect the simple measure of not teaching them C first will do for
this one. I.e. I don't think it the true newbie who hits these
problems, rather someone coming from C. It's not learning how Python
works that confuses, it's the unlearning of how other languages work
that's hard.
In my opinion, anyway. I could be wrong.
I do think there are other reasons why Python isn't a perfect teaching
language (eg. getting Python to run fast being a strange and
non-transferable skill), but I doubt this one.
Cheers,
M.
--
ARTHUR: The ravenours bugblatter beast of Traal ... is it safe?
FORD: Oh yes, it's perfectly safe ... it's just us who are in
trouble.
-- The Hitch-Hikers Guide to the Galaxy, Episode 6
Paul Rubin
> > The best-known attempts to teach children programming have been with
> > the Logo language. See the book Mindstorms, by Seymour Papert. He
> > has another book out called "The Children's Machine: Rethinking School
> > in the Age of the Computer", but I haven't seen it yet.
>
> I have had great success in making children (12-15) having fun programming
> python .... before the were only interested in playing gameboy...with
> pygame, SLT they are now trying to programm a simple game for windows ....
> For Mindstroms there is a python module in work.....
Yes, Python is probably a good choice at ages 12-15. By "children" I
thought of the kids aged maybe 6-8. Python wouldn't make any sense
at that age, but Logo apparently worked ok.
Steve Holden
> Nomad <nomad***@***freemail.absa.co.za> wrote in >...
> > IMHO, python would be one of (if not _the_) best language to teach
> > beginning programming - not just children, but as you mention, there
> > is the difficulty with the "englishness" of the language (or almost
> > any other programming language).
>
> I have my doubts about Python being the first programming language to
> teach. I see all too many newbies running into the problem of
> namespaces. How do you explain to them that "from xyz import *" is a
> bad thing, if they don't even understand what's going on behind the
> scene?
You don't. You simplify, so they initially don't even realise it's possible.
If they don't know they can do something, beginners aren't as likely to get
into trouble by abusing the feature.
> Also, how in the world can beginners understand what a hash
> table mean? Are we going to tell them something like: "oh well, think
> of Python dictionary as a magic black box, you'll understand it later
> when you take a course in C/C++"?
>
You appear to be making the mistake of assuming that the beginner *must*
understand the implementation of an object to be able to use it. If this
were the case we would never learn to drive a car, or to speak natural
languages. A good teacher manages to select useful, and usable, simplifying
assumptions which the beginner can comprehend in terms of their present
understanding. A magic black box isn't a bad way to understand
dictionaries - certainly it's easier for the beginner than looking into hash
functions, buckets, collision chains, and all the other mess that (may) live
under there, and would simply server to confuse.
> Python seems very friendly, at first sight. But unless you really
> understand the dictionary and namespace (and name binding) mechanisms
> behind it, you'll run into surprises in no time. And at that moment,
> there is simply no way that it could be explained in easy terms to
> beginners, when they don't understand things like pointers,
> references, memory stack and heap, hash tables.
>
Certainly the beginner should be taught to expect the unexpected, since it
should not be hidden from them that their understanding is simplified. When
their mental model ceases to fit the language they are probably ready to
have it expanded. But if I accepted your argument, that would logically
imply that a begineer would have to understand RISC/CISC instruction sets
and the von Neumann model before they could write a program in BASIC.
> I do believe Python should be part of a programmer's school
> curriculum, but I really doubt it can be a good first language to
> learn, unless some technicality questions are addressed properly.
>
This is where we differ. I would ignore the difficult bits until they
insistently present themselves to the beginner. "Why doesn't it work like
you taught me" is a great question for a beginner, and until it is asked the
taught level of understanding is adequate.
> Or is there a good way of teaching to make it less traumatic for
> beginners to grasp the concepts of dictionary, name spaces, assignment
> by reference? It is just really really annoying that every single
> newbie has to be explained on these issues, and many of them end up
> without understanding it. I can't imagine teachers having a good time
> at these issues. I mean, it's OK to make students understand these
> Python issues, but the time required is not negligible, and the
> knowledge gained is limited in scope: these peculiarities are very
> Python specific. And it's doubly frustrating when after spending all
> the time, the students end up without understanding it. What can you
> do? It's not the fault of the average students or the average
> teachers, when the language itself has a non-trivial component that's
> hard to explain/understand.
>
Here I believe your focus on what a "newbie" is has changed, to include
programmers arriving at Python via some other language. A programmer who is
familiar with C, or C++, or any other single language, will bring a whole
set of assumptions with them -- and they do, repeatedly, try to transfer
their existing knopwledge to the new language. One who has programmed in
several languages will ask more sensible questions, but they will still need
to know Python specifics. THey will simply have a larger base of referent
concepts to call upon for explanation and enlightenment.
I therefore believe that "Python for C Programmers" would, and should, be a
very different class from "Python for Beginners": the former would have to
focus on differences between the two langugae environments, while the latter
could use many simplifying analogies without ever having to discuss exactly
how lists, tuples, dictionaries and classes are structured and implemented.
regards
Steve
--
http://www.holdenweb.com/
John Roth
"Hung Jung Lu" <hungj...@yahoo.com> wrote in message
news:8ef9bea6.01110...@posting.google.com...
> Nomad <nomad***@***freemail.absa.co.za> wrote in message
news:<bfvcut8gadpces2t1...@4ax.com>...
> > IMHO, python would be one of (if not _the_) best language to teach
> > beginning programming - not just children, but as you mention, there
> > is the difficulty with the "englishness" of the language (or almost
> > any other programming language).
>
> I have my doubts about Python being the first programming language to
> teach. I see all too many newbies running into the problem of
> namespaces. How do you explain to them that "from xyz import *" is a
> bad thing, if they don't even understand what's going on behind the
> scene?
What happens if you want a particular toy from the box,
and you simply empty the entire box on the floor? Then what
happens if you want toys from several boxes, and you empty
all of them on the floor.
There may be a better analogy, but this one should do.
> Also, how in the world can beginners understand what a hash
> table means? Are we going to tell them something like: "oh well, think
> of Python dictionary as a magic black box, you'll understand it later
> when you take a course in C/C++"?
Any child ready to learn a real programming language is
quite capable of understanding a set of keys with tags
hanging on a pegboard. It's a very natural analogy. Just look
at the pegboard and grab the right key!
There are undoubtedly other great analogies, but this one
will undoubtedly do.
John Roth
Tim Peters
> I have my doubts about Python being the first programming language to
> teach. I see all too many newbies running into the problem of
> namespaces. How do you explain to them that "from xyz import *" is a
> bad thing, if they don't even understand what's going on behind the
> scene?
You don't teach them about "import *" at first. Neither metaclasses, nor
that the result of adding two signed float zeroes can depend on the hardware
rounding mode in effect <wink>.
> Also, how in the world can beginners understand what a hash
> table mean?
There's a reason they're called "dictionaries" in Python instead of "hash
tables": if a kid is old enough to look up a definition in a real-life
dictionary, they're old enough to understand the essential nature of a
Python dict. The ABC language (Python's closest predecessor) was
specifically designed for first-time programmers, and testing with newbies
confirmed that dicts (one of only two builtin ABC container types) weren't
hard to master. Goodness, just picture having to teach one of the
alternatives (I'm picturing teaching balanced AVL search trees <wink>).
> Are we going to tell them something like: "oh well, think of Python
> dictionary as a magic black box, you'll understand it later
> when you take a course in C/C++"?
Of course! They don't need to study circuit design to add two integers
effectively either. "An association" is an everyday concept, and how it's
implemented is irrelevant to correct use (BTW, and unlike Python, ABC did
use AVL trees under the covers -- but ABC dict *semantics* were much the
same as Python's).
even-a-"print"-statement-is-heavy-duty-stuff-if-look-deep-enough-ly
y'rs - tim
Paul Rubin
> So, any comments are appreciated, especially on: Are there good reasons
> for advocating python being a language one could teach children
> programming with and are there perspectives in translating python to many
> different languages in order to facilitate this, or will children not be
> ready for learning programming before they have learnt English after all?
What age of children are you talking about? I think not everyone here
is thinking of "children" as meaning the same thing.
Brian Elmegaard
> Guido Stepken <ste...@little-idiot.de> writes:
> > > the Logo language. See the book Mindstorms, by Seymour Papert. He
> >
> > I have had great success in making children (12-15) having fun programming
> > python .... before the were only interested in playing gameboy...with
> Yes, Python is probably a good choice at ages 12-15. By "children" I
> thought of the kids aged maybe 6-8. Python wouldn't make any sense
> at that age, but Logo apparently worked ok.
And I thought about the ages inbetween, I guess. At 8 they don't have
the reading and writing skills to program, at 10 I believe they
do. I will look at pygame.
Brian Elmegaard
> What age of children are you talking about? I think not everyone here
> is thinking of "children" as meaning the same thing.
True, and I find your first answer about logo very interesting. I
think ages 9-12, I guess. After they have learned to read and write
their native language, but they don't necessarily have to have learned
a high level of abstract thinking.
My idea is that programming your own utilities could be taught at
close to the same age as where you begin to learn word processing,
power point,...
Paul Rubin
> And I thought about the ages inbetween, I guess. At 8 they don't have
> the reading and writing skills to program, at 10 I believe they
> do. I will look at pygame.
You could look at Papert's stuff. He was teaching Logo to very young kids.
Paul Rubin
> True, and I find your first answer about logo very interesting. I
> think ages 9-12, I guess. After they have learned to read and write
> their native language, but they don't necessarily have to have learned
> a high level of abstract thinking.
>
> My idea is that programming your own utilities could be taught at
> close to the same age as where you begin to learn word processing,
> power point,...
IIRC, Papert was a student of Piaget, who was one of the big
researchers of child development. Papert's goal in teaching Logo to
very young kids was to teach the idea of debugging at a very early
age--that they should EXPECT things they do to not work the first
time, and to learn how to diagnose and repair the problems, and not
get discouraged.
Sheila King
wrote in comp.lang.python in article <wkpu6ww...@mail.afm.dtu.dk>:
:True, and I find your first answer about logo very interesting. I
:think ages 9-12, I guess. After they have learned to read and write
:their native language, but they don't necessarily have to have learned
:a high level of abstract thinking.
I think you are way over-shooting the mark with age 12. My daughter, age
12 (turning 13 this Friday), has been well beyond just "reading and
writing her native language" for quite some time.
I think that 8 year olds could easily do some simple programming.
Certainly with Logo. And Python could be quite accessible, depending on
how it is presented. Just limit the students to a very small list of
terms that the computer "knows" to start with.
This really is a topic for the edu list, isn't it? I'm sure you would
find many on there telling you that 8 year olds could learn to program.
Simple stuff, of course.
--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/
Laura Creighton
BASIC program that was the hit of his school. He interviewed the
other children in the neighbourhood and got other language translations
for sentences such as ``You smell like a fart.'' and ``You peed in your
shoe.'' Then children would queue up for hours in order to be insulted.
They could then guess the language they were being insulted in, and
if they were wrong they got _more_ insults. They could finally
ask for a translation into the language of their choice. Some languages,
they found out, don't _have_ a noun for fart, as I recall, only a verb.
Many interesting things about languages were learned.
As I recall he and his freind laboured mightily for months on this
project. I am not sure if his school ever found out about it. It was
_the_ _secret_ project. A mathematical ability that was unsure
what division was proved to be no barrier. Thinking back on it now,
I am struck by how much easier he would have had it if he had a decent
exception mechanism.
Laura Creighton
bru...@tbye.com
> Paul Rubin <phr-n...@nightsong.com> writes:
>
> > Guido Stepken <ste...@little-idiot.de> writes:
> > > > the Logo language. See the book Mindstorms, by Seymour Papert. He
> > >
> > > I have had great success in making children (12-15) having fun programming
> > > python .... before the were only interested in playing gameboy...with
>
> > Yes, Python is probably a good choice at ages 12-15. By "children" I
> > thought of the kids aged maybe 6-8. Python wouldn't make any sense
> > at that age, but Logo apparently worked ok.
>
> And I thought about the ages inbetween, I guess. At 8 they don't have
> the reading and writing skills to program, at 10 I believe they
> do. I will look at pygame.
Hi Brian,
As with reading and writing, the age at which kids can start programming
will vary wildly. My 3 year old knows her letters and will probably be
reading long before 8. I was much more of a doofus, but still managed to
learn BASIC at 8 (it was "neat" enough to overcome lack of intelligence &
skills). Also, keep in mind that programming helps develop analytical
skills, so you don't necessarily need to wait until the kid can think
analytically to turn him or her loose on programming.
Woulda been fun to start out with Python...
-Dave
Hung Jung Lu
"How much is set in stone?" thread)
#------------------
flag = 0
def f(x):
flag = 1
return 2*x
y = f(3)
print y, flag
#------------------
output:
6 0
I'd say, most run into this problem soon after they learn to use
functions. It does not matter whether they have seen any other
programming language before or not.
Some have said "don't teach them about 'from xyz import *'". Should we
also not teach beginners about using functions? Python's namespace
feature is such an integral part of the language, that you can't
really neglect it.
Sequence of events:
(1) Teacher goes through the whole song and dance about global, local
namespace. How assignment actually means name binding, etc. etc. It is
fun to do it once, it is fun to do it twice, but after doing it a few
dozen times, teacher gets exhausted, and starts to cast doubt: "...
maybe Python is not such a trivial language, after all."
(2) After being shocked by the above example, students start to put
'global' statements in every single function for every single
variable. They don't understand what is going on, they just don't want
to be bitten by the same bug, again.
(3) After a long (and it can be very long) time stepping on other
namespace landmines, a few students finally come to realize how
namespaces and dictionaries really work. They become teachers, and go
to step (1).
(4) The above is repeated for thousands and thousands of average-level
Python users.
So, given a language that does not have to deal with global/local
namespace pitfalls, and a language that has to deal with it, which one
would you choose as the first language to teach?
Hung Jung
David Andreas Alderud
beginner because they will pick up bad practices, mostly because of the
loose type paradigm.
For teaching programming I strongly belive that Ada95 is by far the best, it
teaches the students how to write good code; I do believe that at least in
universities Python should be the language of choice beyond the first year
studies, unless doing hardware or AI programming.
Jeff Sandys
>
> Hi,
>
> ... Are there good reasons for advocating python
> being a language one could teach children programming ...
Yes, if you are interested in this you should join the
python edu-sig:
http://www.python.org/sigs/edu-sig/
I strongly believe in Computer Programming for Everyone (CP4E).
Every high school graduate should be able to express themselves
with any form of popular expression. They should be able to
write or speak an idea, draw a likeness, sing or play music, and
create a computer algorithm. They don't need to be a star or
make it a vocation, but their expressions should be understood
by others and give a feeling of accomplishment to oneself.
Computers will become more and more prevalent in society.
Microsoft won't be able to provide everyone with the canned
expressions that the user wants to express. There needs to be
an easy to use programming language that allows a high degree
of abstraction. For adults and students Python is that language.
Personally though I use Logo for grammar and middle school
students. Once I develop an adequate curriculum and syllabus I
will use Python in the middle school, because Logo lacks
the ability to do object oriented programming. Elica is an
advanced version of Logo that has some of Python's features.
Perhaps in the future the best features of Logo, simple
syntax and error messages, will be combined with Python's
best features, object oriented, every platform and large
libraries, to make my ideal programming and teaching language.
(Python + Elica => Pelican ?)
Elica reference:
http://www.elica.net
Thanks,
Jeff Sandys
Danyel Fisher
> I'd say, most run into this problem soon after they learn to use
> functions. It does not matter whether they have seen any other
> programming language before or not.
> Some have said "don't teach them about 'from xyz import *'". Should we
> also not teach beginners about using functions? Python's namespace
> feature is such an integral part of the language, that you can't
> really neglect it.
At many schools, Scheme is taught as a first language. It's a lispy language
with nested scopes, and students have _absolutely_ no problem figuring this
out. One way to do it is to start off teaching functions without (gasp!)
global scope. "A function is something that returns stuff." Students who
really need to return multiple things get tuples, so it isn't a big deal.
At some point, you get to say "but there's a slightly easier way,
sometimes." When teaching lisp, the easier way is through the notion of
"environments" and nested scope. In python, we call it a the "globals
list"--a list of variables that you can get at without sending them into a
function.
> Sequence of events:
>
> (1) Teacher goes through the whole song and dance about global, local
> namespace. How assignment actually means name binding, etc. etc. It is
> fun to do it once, it is fun to do it twice, but after doing it a few
> dozen times, teacher gets exhausted, and starts to cast doubt: "...
> maybe Python is not such a trivial language, after all."
Nope. Teacher goes through the short song and dance about local variables
and ignores globals until the students are already comfortable with locals.
> (2) After being shocked by the above example, students start to put
> 'global' statements in every single function for every single
> variable. They don't understand what is going on, they just don't want
> to be bitten by the same bug, again.
Again, the students have good "function" habits. They'll only set the global
"flag" variable when they need to.
You seem to work under the (rather odd) assumption that teaching works by
standing in front of a bunch of students, yelling at them, and then letting
them run off into the world to be confused. Some of us who are teachers
prefer to give students a series of increasingly-sophisticated assignments,
any of which can be solved by the material we've covered so far in class,
and each of which illustrates an interesting principle of the subject
matter.
Kudos, for example, to Kojo Duncan's teacher, who asked a striaghtforward
question ("write a program that lists all prime numbers less than a prime
number a user inputs.") The solution to it requires only traditioanl
functions, few namespaces, and yet is fairly easy.
For students who know prime numbers--not our target audience of 10 year
olds--this is a great assignment.
Danyel
Jeff Sandys
>
> I think that 8 year olds could easily do some simple programming.
This seems to be about the right age to get started in my experience.
While some 2nd graders (about age 7) will get Logo others will
become frustrated, in a large class there are just to many breakdowns
for one teacher to manage. By third grade their spelling and reasoning
abilities are reasonably mature for beginning programming. It is
also useful to put the students in pairs so that they help and
learn from each other, then the teacher can manage the large group.
Thanks,
Jeff Sandys
Carlos Gaston Alvarez
language, so I can speak throught experience.
Childs dont need commands in thear own language.
Most words are new, so they learn the new word as if it where of their own
language.
ex:
imprimir "hello world"
surely you should not learn spanish to know what it means, once you have
read on the manual what it does ... or you have tryed it. So imprimir for
you would mean "print it in the computer's screen"
There is the key point, childs need good documentation in their own
language. I started learning english for real when I realised that if I was
going to learn more about computers, I should learn it in english.
The second great point is that they need a goal, been having fun the best of
all.
My father bought a computer program, so I (the little computer genious)
could learn it and help him on his work. Result, total failure. Later, when
I was grown up, well, I knew what it was expected of me and I realized that
I knew how to do it, it was just that with my child's point on view I found
it useless. If i would have known the real goal may be I would have solved
the 'problem' (there was not a problem at all) but I saw things as useless.
On the other hand I knew (and was doing it ) how to program small computer
games, which where much more complex. So keep in mind the childs point of
view.
So, it seems that the most important for them is that they get the language
doing that they want to do. And HAVE FUN in the process. The lesser the
learning curve, the more reward they have for learning and the more that
they will want to learn. May be that the best way to teach them is to give
them a computer game and teach them how to improve it. Ok, it should not be
too complex. They will add complexity as they learn more.
Chau,
Gaston
> --
> http://mail.python.org/mailman/listinfo/python-list
>
bru...@tbye.com
> How soon does a beginner run into the following problem? (see also the
> "How much is set in stone?" thread)
[snip]
Unfortunately for your argument, most people are not morons. They are
fully capable of learning, and few, if any, will really struggle with this
problem for very long.
I don't think anyone is suggesting Python as a first language because it
is a perfect language - you can find a problem with any choice. But given
the set of languages to choose from, Python's positives outweigh its
negatives as a good choice for beginners.
-Dave
bru...@tbye.com
> Python is without doubt a very good language, but it's not good for the
> beginner because they will pick up bad practices, mostly because of the
> loose type paradigm.
And what bad practices would those be?
> For teaching programming I strongly belive that Ada95 is by far the best
Ugh. At least teach them something that they can use elsewhere. ;-)
> teaches the students how to write good code
Define "good" code, please.
-Dave
Sheila King
comp.lang.python in article <3BE827B7...@juno.com>:
Yes, it was just about five years ago or so, when my daughter was right
about that age (and my son was three years older), that I wrote a small
LOGO-like program in Turbo Pascal. It was interactive. So they could
give the turtle commands like
LEFT 90
MOVE 100
and so forth, and draw little designs on the computer. (Seeing the
results immediately.)
A few months back, my daughter asked me about "that turtle program" that
I had let them "play with" and she said she had liked it and would like
to try it again.
Of course, I don't have Turbo Pascal installed any more, nor do I know
where that code got to that I wrote. When I suggested *really* learning
to program, she seemed less interested. (I did get my son going on some
Python this past summer.) So, for now it appears to be The Sims for
computer entertainment. :/
GerritM
> Yes, it was just about five years ago or so, when my daughter was right
> about that age (and my son was three years older), that I wrote a small
> LOGO-like program in Turbo Pascal. It was interactive. So they could
> give the turtle commands like
> LEFT 90
> MOVE 100
>
> and so forth, and draw little designs on the computer. (Seeing the
> results immediately.)
>
> A few months back, my daughter asked me about "that turtle program" that
> I had let them "play with" and she said she had liked it and would like
> to try it again.
>
> Of course, I don't have Turbo Pascal installed any more, nor do I know
> where that code got to that I wrote. When I suggested *really* learning
> to program, she seemed less interested. (I did get my son going on some
> Python this past summer.) So, for now it appears to be The Sims for
> computer entertainment. :/
>
> --
> Sheila King
> http://www.thinkspot.net/sheila/
> http://www.k12groups.org/
>
distribution? It does all of the "trivial" moves and more. Written by Guido.
I myself have customized it some time ago by making a dutch translation of
the commands.
Regards Gerrit
David Bolen
> How soon does a beginner run into the following problem? (see also the
> "How much is set in stone?" thread)
>
> #------------------
> flag = 0
>
> def f(x):
> flag = 1
> return 2*x
>
> y = f(3)
> print y, flag
> #------------------
> output:
> 6 0
>
> I'd say, most run into this problem soon after they learn to use
> functions. It does not matter whether they have seen any other
> programming language before or not.
Hmm, I'd like to think that learning to use functions would involve
local variables far more than globals. Thus, on the less common case
where you (a) were using globals and (b) needed to overwrite the
global within a local scope, it shouldn't be too hard to introduce the
concept and the global keyword without causing overuse.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
David Bolen
> > For teaching programming I strongly belive that Ada95 is by far the best
>
> Ugh. At least teach them something that they can use elsewhere. ;-)
Of course, to be fair, their odds of using Ada95 again are probably
higher than using Logo ( prominently selected language in this
context), so I'm not sure re-use should be a prominent criterion. :-)
Sheila King
wrote in comp.lang.python in article
:did you have a look at the turtle package in the standard python
:distribution? It does all of the "trivial" moves and more. Written by Guido.
:I myself have customized it some time ago by making a dutch translation of
:the commands.
Yes, I've seen it. One of these days (when I get my round tuit), I will
play with it a bit more. ;)
Hung Jung Lu
The examples I have given ('from xyz import *' and the 'global') are
just, examples. The root of the problem is not the 'from' statement
nor the 'global' statement. Python mailing list has tons and tons of
other examples of beginners running into namespace troubles.
#---------------------
def flipflop(x):
if x == []:
x.append(1)
else:
x = []
a = []
flipflop(a)
print a
flipflop(a)
print a
#---------------------
output:
[1]
[1]
In the above example, the 'global' statement plays no role. Nested
scope is not the problem. Not understanding the namespace mechanism is
the problem.
The root of the non-trivialness is the namespace structure, not any
particular Python statement or keyword. If you think you can explain
to beginners the above example, more than a few dozen times, without
getting exhausted, then I think you will be highly admired. :)
Hung Jung
David Andreas Alderud
> > beginner because they will pick up bad practices, mostly because of the
> > loose type paradigm.
>
> And what bad practices would those be?
Having a non-declarative language as a first choice is bad, teaches them to
write sloppy code.
Having dynamically typed language such as Python does even more damage to
the understanding of how to write good code, thankfully python types are
strong which helps to avoid part of the problem.
> > For teaching programming I strongly belive that Ada95 is by far the best
>
> Ugh. At least teach them something that they can use elsewhere. ;-)
Ada is used quite a lot, especially in the military and general embeded
markets, and it's a gigant in realtime system programming.
Ada is fantastic, with it I write inline Assembly(can even do inline
Fortran, C, C++, etc, etc), combine it with Python, Java, etc, etc.
> > teaches the students how to write good code
>
> Define "good" code, please.
Ada is very strict, so sloppy code is very rare, sloppy written code is bad
code, because it's hard to maintain, debug and extend.
Ada a high level OO language that still remains close to hardware, while
code is still portable across platforms, what more can you ask for?
People underestimate Ada95 because they either don't know jack about Ada or
just know Ada83, use the right tool for the right job, you can after all use
Ada with Python. :-)
Fredrik Lundh
> > And what bad practices would those be?
>
> Having a non-declarative language as a first choice is bad, teaches them to
> write sloppy code.
have you teached python to the kind of people you label as
"them"? or are you just yet another 3l33t language snob?
> Ada is fantastic, with it I write inline Assembly
well, duh. nevermind.
Dr. David J. Ritchie, Sr.
Brian Elmegaard wrote:
....
> So, any comments are appreciated, especially on: Are there good reasons
> for advocating python being a language one could teach children
> programming with
I would like to mention that I've had good success teaching Middle School
students Perl in an after school computer club setting. I have been doing it
since 1998. It took me a couple of try's to come up with an approach that
worked.
First, I took a more text book like approach. That was not very successful.
Then, I took a example by example approach. That worked better.
I started off from an English language perspective as a way of talking about
the syntax and moved more into straight Perl.
I tried to key it to the "language arts" curriculum and the push for literacy so
the focus was to learn enough Perl to write a "Choose Your Own Adventure"
game. In one very successful club season, I ended up with 16 different "adventures"
written by kids on their own, ranging from Teletubbies to "Bill Gates vs. Apple Computer".
Though they learned other aspects of Perl, the adventure program mainly involved
if statements and print statements. For some in the sixth, seventh, and eighth grades,
abstract thinking is only just starting to turn on, so the concreteness of the adventure
program was an asset.
This season I'm going to try to do the Computer Club sessions again but with
Python instead of Perl. It should be lots of fun.
You can see the Perl handout for the later successful sessions at
http://home.mindspring.com/~djrassoc01/PoP/Pop1.html
You can see the evaluation of the first attempt and some discussion about the
experience at:
http://home.mindspring.com/~djrassoc01/previous/VolunteerActivities/Washington/perl.html
In a couple of months, I will post to my web site my experiences doing similar things with Python.
--David
--
Dr. David J. Ritchie
djras...@mindspring.com
http://home.mindspring.com/~djrassoc01/
Huaiyu Zhu
>#---------------------
>def flipflop(x):
> if x == []:
> x.append(1)
> else:
> x = []
>
>a = []
>flipflop(a)
>print a
>flipflop(a)
>print a
>#---------------------
>output:
>[1]
>[1]
>
>In the above example, the 'global' statement plays no role. Nested
>scope is not the problem. Not understanding the namespace mechanism is
>the problem.
>
>The root of the non-trivialness is the namespace structure, not any
>particular Python statement or keyword. If you think you can explain
>to beginners the above example, more than a few dozen times, without
>getting exhausted, then I think you will be highly admired. :)
You are confused about the cause of this problem. It is has nothing to do
with namespace. It is no more complicated than the following
>>> a = []
>>> x = a
>>> x.append(1)
>>> print a
[1]
>>> x = []
>>> print a
[1]
What is going on? Well, remember the following two points:
1. Python distinguishes between names and objects. So when you see names
like a, x, ask yourself whether they refer to the same object.
2. Python distinguishes between mutation and name-binding. Mutating an
object will show the result in all names that point to this object.
Rebinding a name to another object will not affect other names, even if
they refer to the same object before.
These two points should be easily explainable to newbies using simple
analogies, such as tags tied to objects with strings.
feeling-exhausted-explaining-this-many-times-ly yr's
Huaiyu
Cliff Wells
> Having a non-declarative language as a first choice is bad, teaches them to
> write sloppy code.
Yes and no. Like many others, my first language was BASIC (on an Apple //e).
Later, I took some CS classes where we learned Pascal. I had indeed
developed some bad habits due to language deficiencies in BASIC (everything
global, no argument passing, jumping in and out of routines, etc). However,
it was a good, simple introduction to programming and I like to think I
wasn't permanently crippled by the experience. Later, I took up C, and what
do you know? Pascal gave me "bad" habits (mostly in the area of counting
upon the compiler to warn me about bad things I was about to do). However, I
would never have moved back to Pascal from C because C's flexibility allowed
me to code things that would have been extremely difficult in Pascal. Yes, I
could shoot myself in the foot, but at least I had a gun.
> Having dynamically typed language such as Python does even more damage to
> the understanding of how to write good code, thankfully python types are
> strong which helps to avoid part of the problem.
That depends upon your perspective on what "good code" is. Code that is easy
to read? Easy to modify? One of Python's strengths is that almost every
line of code is related to solving the programmer's goal rather than telling
the compiler how to compile the code. Not having a lot of extra statements
that have nothing to do with solving the problem results in cleaner, easier
to understand code. The skills you are referring to are difficult to teach
in any language (although, I can't comment on Ada - perhaps it makes
designers out of neophytes in no time ;-) . These come with time and
experience.
> Ada is used quite a lot, especially in the military and general embeded
> markets, and it's a gigant in realtime system programming.
Not really areas of interest for beginners.
> Ada is fantastic, with it I write inline Assembly(can even do inline
> Fortran, C, C++, etc, etc), combine it with Python, Java, etc, etc.
It may be. Many excellent languages languish in specialized niches. However
I would hesitate making one of those excellent languages a teaching tool
since people learning it would undoubtedly have to later move to another
language anyway (possibly due to lack of availability on a specific
platform), so most of the features they've come to depend upon would no
longer be available and their reliance upon them would show up as "bad
programming practices" in their new language.
> Ada is very strict, so sloppy code is very rare, sloppy written code is bad
> code, because it's hard to maintain, debug and extend.
Not knowing Ada makes me reluctant to disagree, but I wonder how a language
so strict that writing sloppy code is difficult can be a very flexible
language. Usually those things are mutually exclusive. Training-wheels on a
bicycle are a common comparison... safety over flexibility. Maybe this is
why you need inline Fortran/C/Assembly in your Ada code - to get around the
restrictions of the language.
> Ada a high level OO language that still remains close to hardware, while
> code is still portable across platforms, what more can you ask for?
Widespread use? A promising future? Guido himself suggested (in Linux
Journal) that perhaps Dylan was slightly better than Python in some respects,
but I don't see anyone jumping ship just yet (maybe when Visual Dylan hits
the market).
> People underestimate Ada95 because they either don't know jack about Ada or
> just know Ada83, use the right tool for the right job, you can after all
> use Ada with Python. :-)
True, I don't know jack about Ada. I don't know jack because I've never
known anyone (other than yourself) who claims to use it. This doesn't make
it a bad language, just an impractical one. The unfortunate fact is that the
best design doesn't always win (otherwise where would Microsoft be today?).
I think Ada had its chance and failed to claim enough interest to make it
relevant today.
And please, I'm not trying to offend you, just disagree with you (a little),
so let's not make this another flame war - this list has had too many the
last couple of days.
Regards,
--
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308
Hung Jung Lu
Huaiyu Zhu wrote:
> You are confused about the cause of this problem.
I don't think so.
> It is has nothing to do with namespace.
Now you are confused. You think you can do Python without namespaces.
statement modification on the globals() namespace dictionary
----------------+------------------------------------------------------
>>> a = [] | (1) yes, entry with key 'a' inserted
>>> x = a | (2) yes, entry with key 'x' inserted
>>> x.append(1) | (3) no, no action on globals() namespace dictionary
>>> print a |
[1] |
>>> x = [] | (4) yes, value of the entry with key 'x' updated
>>> print a |
[1] |
The difference in (3) and (4) is simply whether action has been
performed on the namespace dictionary, regarding the entry with key
'x'.
(Forgive me for not entering into issues on pointers and objects in
the heap, I don't want to open another can of worms.)
It is perhaps more instructive to see this:
globals().update({'x': 3})
y = x+1
print x, y
And from there you can understand that there is a namespace operation
whenever you talk about binding. The difference between your example
and my example is simply that your 'x' lives in the globals namespace,
mine lives in the locals namespace, which is not the point. The point
is one has to understand that Python's assignments, Python's 'global'
statement, Python's 'from xyz import *' statement, etc. are merely
syntactic sugar, and that the actual operations are performed on the
namespace dictionaries. And remember, we are not talking about people
here not understanding Python, we are talking about how it is hard to
explain to beginners these things.
Experienced Python programmers always keep the three Python namespaces
in mind. Matter of fact, many good Python programmers, including those
that made Zope and hired Guido [:)], do tweak the built-in namespace
once in a while. I guarantee you, once you have the namespace
dictionaries picture inside your head, you won't need to use terms
like "Python distinguishes between mutation and name-binding" and you
won't run into namespace problems again. Once you understand the
namespace dictionary mechanism, you'll see that all the three examples
('from xyz import *', 'global', and this one) I have mentioned all
come from the lack of understanding of the namespace mechanism.
Without understanding the namespace mechanism, you think they are
three unrelated problems. (Missing the forest because of the trees, as
they say in English, or, like blindmen touching the elephant, as they
say in Chinese.) Once understood the namespace mechanism, you won't
have any of these problems. Frankly, I don't think a person has
understood Python until they have understood the namespace mechanism.
My advise is: get to see the whole forest, or the whole elephant, or
the whole Python. :)
However, that's not a task for beginners. Me having to spend 4
postings on this thread should tell you something: many people don't
see the whole Python.
>feeling-exhausted-explaining-this-many-times-ly yr's
Believe me, I am more exhausted than you are. :)
Hung Jung
Brian Elmegaard
> Yes, if you are interested in this you should join the
> python edu-sig:
> http://www.python.org/sigs/edu-sig/
Done.
> I strongly believe in Computer Programming for Everyone (CP4E).
'everybody' it says, even though there probably is no distinction.
> Every high school graduate should be able to express themselves
> with any form of popular expression. They should be able to
Exactly.
> create a computer algorithm. They don't need to be a star or
!
> of abstraction. For adults and students Python is that language.
> Personally though I use Logo for grammar and middle school
> students. Once I develop an adequate curriculum and syllabus I
I have to check out logo.
> Thanks,
and to you,
Brian Elmegaard
[snip]
Carlos, these are all really good points, which I agree on,
particularly of course the distinction between the language used for
programming and the language of the documentation.
The idea with a game to improve seems to be quite interesting.
Paul Rubin
> I have to check out logo.
Here's a Logo FAQ:
http://www.erzwiss.uni-hamburg.de/Sonstiges/Logo/logofaqx.htm
Brian Elmegaard
> On Tuesday 06 November 2001 15:07, David Andreas Alderud wrote:
>
> > Having a non-declarative language as a first choice is bad, teaches them to
> > write sloppy code.
>
> Yes and no. Like many others, my first language was BASIC (on an
> Apple //e). Mine too on Commodore 64 . > Later, I took some CS
> classes where we learned Pascal. I had indeed > developed some bad
>habits due to language deficiencies in BASIC (everything > global, no
>argument passing, jumping in and out of routines, etc). However, > it
>was a good, simple introduction to programming and I like to think I >
>wasn't permanently crippled by the experience.
Me too.
> That depends upon your perspective on what "good code" is. Code
> that is easy to read? Easy to modify? One of Python's strengths is
> that almost every line of code is related to solving the
> programmer's goal rather than telling the compiler how to compile
> the code. Not having a lot of extra statements that have nothing to
> do with solving the problem results in cleaner, easier to understand
> code.
Exactly, you don't have to do it perfectly, when you start learning
how to do it. In schools nowadays you are awarded for a cribbled,
backwards, upside-down G, the first day and is punished for it two
years after. I believe this must be the way you should teach
programming, too. No reason to worry about all the perfectionist stuff
at first.
Paul Rubin
> Brian Elmegaard <br...@rk-speed-rugby.dk> writes:
> > I have to check out logo.
>
Oh wow, I hadn't seen this site before (The Logo Foundation):
David Andreas Alderud
//e).
> Later, I took some CS classes where we learned Pascal. I had indeed
> developed some bad habits due to language deficiencies in BASIC
(everything
> global, no argument passing, jumping in and out of routines, etc).
However,
> it was a good, simple introduction to programming and I like to think I
> wasn't permanently crippled by the experience. Later, I took up C, and
what
> do you know? Pascal gave me "bad" habits (mostly in the area of counting
> upon the compiler to warn me about bad things I was about to do).
However, I
> would never have moved back to Pascal from C because C's flexibility
allowed
> me to code things that would have been extremely difficult in Pascal.
Yes, I
> could shoot myself in the foot, but at least I had a gun.
I hear you, but it's my experience when teaching at the university that
students that start with non-declarative languages write sloppy code. All is
relative of cource, but I just speak from my own experience, myself I
started with MC68k assembly and went to BASIC and E, and picked up some
really bad habits in BASIC that took months to overcome.
> That depends upon your perspective on what "good code" is. Code that is
easy
> to read? Easy to modify? One of Python's strengths is that almost every
> line of code is related to solving the programmer's goal rather than
telling
> the compiler how to compile the code. Not having a lot of extra
statements
> that have nothing to do with solving the problem results in cleaner,
easier
> to understand code. The skills you are referring to are difficult to
teach
> in any language (although, I can't comment on Ada - perhaps it makes
> designers out of neophytes in no time ;-) . These come with time and
> experience.
I love Python, I advocate it a lot, but I believe that Ada95 is the prime
language for beginners.
Python's biggest strength from my point of view is the fact that it is
master tool for fast prototyping, but you can't really take full advantage
of that feature in a project until you have a lot of experience with low
level languages.
> Not really areas of interest for beginners.
Depends on the beginner ;-)
> It may be. Many excellent languages languish in specialized niches.
However
> I would hesitate making one of those excellent languages a teaching tool
> since people learning it would undoubtedly have to later move to another
> language anyway (possibly due to lack of availability on a specific
> platform), so most of the features they've come to depend upon would no
> longer be available and their reliance upon them would show up as "bad
> programming practices" in their new language.
The fact that Ada is the only language that truly was designed, people who
have used Ada have no problem to pick up other langauges other than fully
functional languages such as LISP.
> Not knowing Ada makes me reluctant to disagree, but I wonder how a
language
> so strict that writing sloppy code is difficult can be a very flexible
> language. Usually those things are mutually exclusive. Training-wheels
on a
> bicycle are a common comparison... safety over flexibility. Maybe this is
> why you need inline Fortran/C/Assembly in your Ada code - to get around
the
> restrictions of the language.
No, not infelxiblitity, it's just that my first language was assembly so I
tend to use inline assembly instead of banging the hardware in Ada. Call it
a birth defect, a defect that I would not have if I had started with Ada.
> Widespread use? A promising future? Guido himself suggested (in Linux
> Journal) that perhaps Dylan was slightly better than Python in some
respects,
> but I don't see anyone jumping ship just yet (maybe when Visual Dylan hits
> the market).
I see big demand for Ada programmers here in Sweden, not as big as Java and
C++, but indeed much more so than Python :)
Airbus in France use Ada almost exclusivly, if my friend who works there is
correctly informed.
> True, I don't know jack about Ada. I don't know jack because I've never
> known anyone (other than yourself) who claims to use it. This doesn't
make
> it a bad language, just an impractical one. The unfortunate fact is that
the
> best design doesn't always win (otherwise where would Microsoft be
today?).
> I think Ada had its chance and failed to claim enough interest to make it
> relevant today.
Think of Ada as kind of Objective-C of all oo iterative languages, more
powerful and better syntax than C++, but not as accepted.
I see a growing market for Ada, though I rarely code in Ada anymore (mostly
Python), I do this because I prefer the fast prototyping of Python.
I believe that Ada is a better choise for the beginner, I'm not claiming to
hold the absolute truth.
> And please, I'm not trying to offend you, just disagree with you (a
little),
> so let's not make this another flame war - this list has had too many the
> last couple of days.
I got nothing to get mad about, I love Python, I just believe that Ada is a
better language to begin with.
I must say I'm anti-GNU, i.e. anti-GPL/LGPL, but I found this which was an
interesting quote from a GPL'ed project:
"Using GtkAda and GNAT, we can decrease time to market by a factor of two to
four over any other language/compiler."
-- http://libre.act-europe.fr/gvd/
David Andreas Alderud
to
> > write sloppy code.
>
> have you teached python to the kind of people you label as
> "them"?
Yes.
> or are you just yet another 3l33t language snob?
Isn't this nice, semi-ad hominem attack by a person with strong
economical/commertial interests in Python; you don't think you might just be
a little too biased to take part in this kind of discussion?
> > Ada is fantastic, with it I write inline Assembly
>
> well, duh. nevermind.
If you don't have anything worthwhile to say, don't say it.
Emile van Sebille
"Hung Jung Lu" <hungj...@yahoo.com> wrote in message
news:8ef9bea6.0111...@posting.google.com...
> hua...@gauss.almadan.ibm.com (Huaiyu Zhu) wrote in message
news:<slrn9uh4ru...@gauss.almadan.ibm.com>...
<snip>
> However, that's not a task for beginners. Me having to spend 4
> postings on this thread should tell you something: many people don't
> see the whole Python.
>
Good examples. Still, as it pertains to teaching younger children,
explaining two simple rules fix it: don't re-use names within the same
module; and, if you want values back from a function you have to ask for
them (use return). Then, when something doesn't appear to work right, you
can point to the broken rule, the child says "Oh.. yeah.." and you both move
on. When things progress to the point ("Oh.. yeah..Why?" ) where
understanding mutability and namespaces is possible, then it's time to move
a further step forward in a more complete review.
With these rules (and possibly a few more), I won't hesitate to start my
kids out on python. Besides, why would you want to start them out on
anything else? ;-)
--
Emile van Sebille
em...@fenx.com
---------
Steve Holden
> hua...@gauss.almadan.ibm.com (Huaiyu Zhu) wrote >...
>
[...]
> > You are confused about the cause of this problem.
>
> I don't think so.
>
> > It is has nothing to do with namespace.
>
> Now you are confused. You think you can do Python without namespaces.
>
namespaces". In so far as names have to live somewhere, clearly they are
necessary. Just the same, you should be careful, having found a hammer, not
to confuse all problems with a nail.
Object mutability is also an important aspect of the problem described.
Because the object is referred to by name does not make all problems
concerning it "namespace problems". And I am not, by the way, trying to
suggest that understanding namespaces isn't essential to a complete
understanding of Python. I am simply trying to suggest that, didactically
speaking, understanding cannot be complete instantly, and it is therefore
necessary to provide a staged set of comprehension levels for beginners. In
the early stages, unnecessary complications (those which don't improve
understanding) should be omitted.
>
> Experienced Python programmers always keep the three Python namespaces
> in mind. Matter of fact, many good Python programmers, including those
> that made Zope and hired Guido [:)], do tweak the built-in namespace
> once in a while. I guarantee you, once you have the namespace
> dictionaries picture inside your head, you won't need to use terms
> like "Python distinguishes between mutation and name-binding" and you
> won't run into namespace problems again. Once you understand the
> namespace dictionary mechanism, you'll see that all the three examples
> ('from xyz import *', 'global', and this one) I have mentioned all
> come from the lack of understanding of the namespace mechanism.
> Without understanding the namespace mechanism, you think they are
> three unrelated problems. (Missing the forest because of the trees, as
> they say in English, or, like blindmen touching the elephant, as they
> say in Chinese.) Once understood the namespace mechanism, you won't
> have any of these problems. Frankly, I don't think a person has
> understood Python until they have understood the namespace mechanism.
> My advise is: get to see the whole forest, or the whole elephant, or
> the whole Python. :)
>
The different problems have related caused, true. This does not mean that a
beginner shouod be confused by having full detail of the namespace
mechanisms thrust at them when all they need to do is bind values to a name
or two. Your use of the term "understanding" omits any comparative, implying
that there is only one level of understanding. We must find out many
individual facts about the elephant before we appreciate its true
complexity. In the meantime are we not allowed to use it to haul logs?
> However, that's not a task for beginners. Me having to spend 4
> postings on this thread should tell you something: many people don't
> see the whole Python.
>
I suspect it is more a measure of your determination to have this matter
thoroughly discussed. Would you like to go for 5 :-) ...?
> >feeling-exhausted-explaining-this-many-times-ly yr's
>
> Believe me, I am more exhausted than you are. :)
>
Newbies are easy. It's the old-timers who are hard to convince!
not-that-i-claim-to-be-one-ly y'rs - steve
--
http://www.holdenweb.com/
Arthur Siegel
Cliff writes -
>One of Python's strengths is that almost every
>line of code is related to solving the programmer's
>goal rather than telling the compiler how to
>compile the code.
Which has been my experience, and why I think
I was more successful with Python than with
other languages I false-started with before I
came to it.
In effect, my interest was not in learning
programming, but in accomplishing some things
for which an understanding of programming
happens to have been an essential.
In the educational setting, I think it is much
more important to focus, in the end, on what
an understanding of programming fundamentals
brings to the table generally - rather than viewing
it as an isolated educational goal. Invest in
giving students that understanding because it will
allow for enhanced curriculum in subjects X,Y,
and Z. Math and science being the obvious.
Looked at in this way, Python - in my view -
particularly well fits the setting.
Art
Steve Holden
[...]
> The fact that Ada is the only language that truly was designed,
Please. This sweeping generalisation lays all your other arguments waste.
regards
Steve
--
http://www.holdenweb.com/
Laura Creighton
>
> I hear you, but it's my experience when teaching at the university that
> students that start with non-declarative languages write sloppy code. All is
> relative of cource, but I just speak from my own experience, myself I
> started with MC68k assembly and went to BASIC and E, and picked up some
> really bad habits in BASIC that took months to overcome.
This is really interesting, because my experience is exactly the
opposite. I have no doubt that you learned some very bad habits when
you learned BASIC, but it is not clear to me how you got from that
fact to the conclusion that it was the fact that BASIC is not typed
that ruined you.
I believe that assembler is bad for you in much the same way that strongly
typed languages are bad for you. Unless you really have to tickle the
hardware, in which case how many bits there are in something is part
of your problem domain, any representation of your problem that forces
you to keep track of such things is doing damage to you as a problem
solver. If you have to talk to the hardware, by all means use a
strongly typed language. Otherwise, stay away.
We had a good representative of this kind of bad thinking yesterday.
Somebody wanted help with his isnumeric function. Lines and lines
and lines of code all trying to test to see if a particular string
was possibly a number when all he needed was:
>>> def isnumeric(s):
... try:
... f=float(s)
... return 1
... except ValueError:
... return 0
...
which I mailed him. Poor soul. Somebody ruined him by teaching him
that computers operate on types. Now he has to fix himself. I'd recommend
a steady diet of Smalltalk until he no longer remembered what types were,
nay, until the idea of types positively annoyed him, but that might be
hard to arrange.
The other day Tim Peters wrote:
In a world where 3/4 == 0, how long could any programmer
survive believing that integer division and multiplcation are
"inverses"? The antecedent is dead on arrival.
This is very true. But it demonstrates that the man has been hanging out
with the bits and the types for too long. It has done interesting things
to his skull. Precise, competant, and excellent professional things,
for somebody that has to care about exactly where the bits go, but it
blinds him to the plea 'Awwww. but I wanted multiplication and division
to be _inverses_!' And that is a poignant cry from somebody whose
problem domain _doesn't_ include bits, bytes, and how you order them
in a computer.
This leads me to believe that it is likely that we have different
standards for sloppy code. Do you mean 'written with little or no
concern as to where the bits are?'. That's a different sort of
sloppiness than the sort that usually bothers me, unless of course I
am writing a device driver or a compiler or something that _cares_.
From my point of view, _any_ version of isnumeric that doesn't use
try and except is sloppy, no matter how much precision went into
determining all the possibly string inputs and what to do with each
case. (Unless you are Tim Peters, and rewriting format, for instance.)
It is the sloppiness of bringing the wrong part of your mind to your
job. Shooting flies with anti-aircraft guns. And strongly typed
languages encourage you to think on too low a level of abstraction
for most programming problems.
I am curious: my experience with C++ has made me conclude that the
only people who are any good at programming C++ were also good at
programming assembler when they learned C++. (Or until they learned
assembler, they remained foul C++ programmers. I _do_ know one person
who was a rotten C++ programmer until he took an assembler course, at
which point he got a lot better.) Does your experience differ so
much? Are there many good Ada programmers who know little or no
assembler? If so, I would think that this is evidence that there is
something other than the strong typing that makes Ada a good first
programming language. C++ certainly isn't a good first language, and
neither is BASIC, but the flaws in both those languages seem to be far
deeper than how strongly typed they are.
> I see big demand for Ada programmers here in Sweden, not as big as Java and
> C++, but indeed much more so than Python :)
Are they all in Lund? I know people who would like to get an Ada job,
which they aren't finding here in Göteborg.
all this is very interesting to me,
thanks for writing,
Laura Creighton
David Andreas Alderud
Ada was well documented and with lots of RFC before the actually
implementation of Ada83. Considering that it took 7 years of design before
the next version of Ada to be finnished, it started in '88.
I might be wrong, but I'm not aware of a language that was publicly designed
for years before its first implementation, if you know something I don't,
please enlighten me.
Yes, most languages are designed, but not from start to finnish, more like
version 1.0 and forward, that is not _what I call design_, maybe because I'm
schooled in software architectures, I don't know.
Maybe we have different opinions of design, I think of design as in
architectural design.
Fredrik Lundh
> > The fact that Ada is the only language that truly was designed,
> [...]
> Please. This sweeping generalisation lays all your other arguments waste.
oh, give him a little slack. it might be true that the computer science
department at his university isn't exactly the best one in Sweden (hardly
his fault), but he has a point there: Ada wasn't just designed once, but
twice.
unlike e.g. Scheme, which we all know was discovered, not designed.
(and we all know that the van Rossum's don't know anything about
design ;-)
</F>
Fredrik Lundh
> Exactly, you don't have to do it perfectly, when you start learning
> how to do it. In schools nowadays you are awarded for a cribbled,
> backwards, upside-down G, the first day and is punished for it two
> years after.
what many people are missing is that in real life, the software
equivalents to backwards upside-down G's are often good enough.
even two years later.
</F>
Steve Holden
> Java, C and C++ got there after a while, but they where not to begin with.
> Ada was well documented and with lots of RFC before the actually
> implementation of Ada83. Considering that it took 7 years of design before
> the next version of Ada to be finnished, it started in '88.
> I might be wrong, but I'm not aware of a language that was publicly
designed
> for years before its first implementation, if you know something I don't,
> please enlighten me.
Given what you've said, I guess I'll accept that Ada had a lot of upfront
design - I'm not here simply to disagree! I presume you mean strawman,
stoneman, ironman? OK, but in that case how come there had to be a "next
version"? Clearly all that up-front design didn't produce a perfect
language. How is this different (except perhaps in terms of gestation time)
from other standardised languages?
> Yes, most languages are designed, but not from start to finnish, more like
> version 1.0 and forward, that is not _what I call design_, maybe because
I'm
> schooled in software architectures, I don't know.
>
> Maybe we have different opinions of design, I think of design as in
> architectural design.
>
Well you surely don't believe that *buildings* are built exactly as they are
conceived? Why else do the construction teams have to supply "as built"
drawings - because they have to modify the building design as construction
progresses, to take into account the practical considerations of the site,
materials, etc.
Software is difficult precisely because it is so malleable, and so a design
can evolve. This is both a good and a bad thing. But none of this really has
to do with suitability as a teaching language, and I still don't see Ada as
any better for teaching purposes than Python.
David Andreas Alderud
>opposite. I have no doubt that you learned some very bad habits when
>you learned BASIC, but it is not clear to me how you got from that
>fact to the conclusion that it was the fact that BASIC is not typed
>that ruined you.
I guess this depends on where one gets schooled, where I come from the
differences of datatypes and the use are really important.
One thing that I hate to remind myself of is the use of optimal types for a
specific architecture, when I started with BASIC(a MacroAssembler based
BASIC) in the late 80's I forgot the importance of choosing the datatypes
with care and it's a handicap that still plagues me.
No knowing the importance is not the same as not feeling the effects of bad
choices.
>I believe that assembler is bad for you in much the same way that strongly
>typed languages are bad for you. Unless you really have to tickle the
>hardware, in which case how many bits there are in something is part
>of your problem domain, any representation of your problem that forces
>you to keep track of such things is doing damage to you as a problem
>solver. If you have to talk to the hardware, by all means use a
>strongly typed language. Otherwise, stay away.
Yes, I totally agree. On the other hand it's hard to make maximum use of a
language/compiler without the knowledge of compiler design, to really
understand compiler design one has to know hardware.
I'm probably damaged from the fact that I started in a bottom-up learning,
maybe top-down is really to prefer, in either way Ada95 is the middle way,
and I believe that the middle is the best way to reach a wide set of quasi
perfect goals.
>We had a good representative of this kind of bad thinking yesterday.
>Somebody wanted help with his isnumeric function. Lines and lines
>and lines of code all trying to test to see if a particular string
>was possibly a number when all he needed was:
>>> def isnumeric(s):
... try:
... f=float(s)
... return 1
... except ValueError:
... return 0
...
>which I mailed him. Poor soul. Somebody ruined him by teaching him
>that computers operate on types. Now he has to fix himself. I'd recommend
>a steady diet of Smalltalk until he no longer remembered what types were,
>nay, until the idea of types positively annoyed him, but that might be
>hard to arrange.
Smalltalk is an amazing language, but since I belong in the university world
the number of choices one can make within CS are so diverse that a language
that teaches the middle way is to be preferred.
Maybe Python is to be preferred if all the students will ever do is to write
programs at such type of language.
>The other day Tim Peters wrote:
>In a world where 3/4 == 0, how long could any programmer
>survive believing that integer division and multiplcation are
>"inverses"? The antecedent is dead on arrival.
One of my reasons for rejecting Python as a language for teaching is the
fact that 3/4 is in fact 0, though I believe it will be corrected in 2.2, am
I correct?
The other reason is the fact that as Python is a non-declarative language a
beginner might do a mistake like:
>>> x = 1.0
[...]
>>> X = some calculation
[...]
>>> if x==1.0:
>>> do some stuff
>>> else:
>>> do something else
I hope you can see the dangers in this, with Ada it is avoided. The person
learns how to use datatypes and declarations correctly.
>This is very true. But it demonstrates that the man has been hanging out
>with the bits and the types for too long. It has done interesting things
>to his skull. Precise, competant, and excellent professional things,
>for somebody that has to care about exactly where the bits go, but it
>blinds him to the plea 'Awwww. but I wanted multiplication and division
>to be _inverses_!' And that is a poignant cry from somebody whose
>problem domain _doesn't_ include bits, bytes, and how you order them
>in a computer.
:-)
>This leads me to believe that it is likely that we have different
>standards for sloppy code. Do you mean 'written with little or no
>concern as to where the bits are?'. That's a different sort of
>sloppiness than the sort that usually bothers me, unless of course I
>am writing a device driver or a compiler or something that _cares_.
True, very true. As you said, it might be an environmental damage from my
assembly background.
>From my point of view, _any_ version of isnumeric that doesn't use
>try and except is sloppy, no matter how much precision went into
>determining all the possibly string inputs and what to do with each
>case. (Unless you are Tim Peters, and rewriting format, for instance.)
>It is the sloppiness of bringing the wrong part of your mind to your
>job. Shooting flies with anti-aircraft guns. And strongly typed
>languages encourage you to think on too low a level of abstraction
>for most programming problems.
Yes, but then, aren't we supposed to teach programmers how the computers
work? Or am I just a relic of the ancient world of bits, shifts and
rotations.
>I am curious: my experience with C++ has made me conclude that the
>only people who are any good at programming C++ were also good at
>programming assembler when they learned C++. (Or until they learned
>assembler, they remained foul C++ programmers. I _do_ know one person
>who was a rotten C++ programmer until he took an assembler course, at
>which point he got a lot better.) Does your experience differ so
>much? Are there many good Ada programmers who know little or no
>assembler? If so, I would think that this is evidence that there is
>something other than the strong typing that makes Ada a good first
>programming language. C++ certainly isn't a good first language, and
>neither is BASIC, but the flaws in both those languages seem to be far
>deeper than how strongly typed they are.
Personally I believe that it isn't possible to write good code in C++,
because the language is void, IMNSHO.
My experience with assembly programmers is that they write so-so C++ code,
but C++ programmers make very bad assembly programmer.
The only thing that is so-so about Ada is complaints from the hardcore OO
developers, the fact that Ada lacks multiple inheritance; I consider the
lack of multiple inheritance a feature, because neither does Java, as use of
MI is(considered) a bad practice. While Ada lacks MI, it does support the
construction of multiple inheritance type hierarchies through the use of
generics and type composition.
The strongest features for me in Ada is the clean syntax and packages
methodology, the generic packages is a very good language construct which I
miss in ever single language that I come across.
The fact that most developers of Ada don't know assembly language is a good
sign, though many do know assembly as they have been working for the
military for a long time.
>Are they all in Lund? I know people who would like to get an Ada job,
>which they aren't finding here in Göteborg.
Before the .COM crisis WM-DATA used to vacuum clean the market, a friend
used to work as an Ada programmer in Göteborg for VM-DATA. It's really hard
to find any kind of jobs in the tech industry these days, but if they don't
mind working with hardware(embedded devices) it shouldn't cause any
problems. They should make contact with the Swedish military, they always
want new talented Ada developers.
Huaiyu Zhu
>
>> It is has nothing to do with namespace.
>
>Now you are confused. You think you can do Python without namespaces.
I did not know I thought that. Thank you for telling me what I thought. :-)
>
> statement modification on the globals() namespace dictionary
>----------------+------------------------------------------------------
>>>> a = [] | (1) yes, entry with key 'a' inserted
>>>> x = a | (2) yes, entry with key 'x' inserted
>>>> x.append(1) | (3) no, no action on globals() namespace dictionary
>>>> print a |
>[1] |
>>>> x = [] | (4) yes, value of the entry with key 'x' updated
>>>> print a |
>[1] |
>
>The difference in (3) and (4) is simply whether action has been
>performed on the namespace dictionary, regarding the entry with key
>'x'.
Oh, now I see what you mean. You are saying anything that concerns names is
a namespace problem. Of course that would be everywhere. But that's
exactly why you find it difficult to explain to newbies.
Have you considered the alternative approach? That is to separate the two
issues:
1. name binding vs mutation,
2. name binding in different namespaces.
To explain the example, you only need to touch upon the first issue. And it
is considerably easier, as your one sentence summary quoted above shows.
I would only call the second issue as namespace problem. However, as long
as the first one is well understood, the second is not hard either - It's
just the scoping rules.
[snip long-winded discussion about namespace mechanisms]
>However, that's not a task for beginners. Me having to spend 4
>postings on this thread should tell you something: many people don't
>see the whole Python.
Or maybe many people don't see the point of weighing in the knowledge of the
whole Python in order to explain this simple example?
>>feeling-exhausted-explaining-this-many-times-ly yr's
>
>Believe me, I am more exhausted than you are. :)
>
Maybe that's because you are trying to explain too much in one go?
divide-and-conquer-works-ly yr's
Huaiyu
David Bolen
> Not knowing Ada makes me reluctant to disagree, but I wonder how a language
> so strict that writing sloppy code is difficult can be a very flexible
> language. Usually those things are mutually exclusive. Training-wheels on a
> bicycle are a common comparison... safety over flexibility. Maybe this is
> why you need inline Fortran/C/Assembly in your Ada code - to get around the
> restrictions of the language.
Generally it works out because in the areas that Ada is strict, it
also contains a wide variety of declarative capability in order to
provide the needed flexibility. Although I don't think I'd be as
confident to say that sloppy code can't be written in Ada, since it's
easier to write neater code with built-in language features, I do
expect that in general code is less sloppy.
As one example, while Ada's type system is strict and includes
features such as range and value checking (both compile and runtime)
to lock down a wide variety of coding errors, it also permits enough
declarative information to be encoded in the source to give the
compiler enough information to perform those checks while still
permitting the application to accomplish its goals without trying to
defeat the protection. You work with the type safety system rather
than against it.
In Ada, you don't tend to just define variables as integers, or
floating point, but rather with appropriate ranges, as subtypes of
other existing types, etc... Enumerations are hard types and not just
substitutes for integer values. The compiler and runtime enforce type
rules, but it's a nice synergy with the more flexible declarations.
To be honest, I see a lot of similarity of the strong typing between
Ada and Python - it's just that Python pushes everything dynamic and
at runtime, while Ada contains lots of language features for static or
compile time type handling. Both of them contrast with something like
C/C++ where many types - particularly numeric - are coerced and
converted automatically all the time behind the covers and without any
explicit source support for such conversion.
I don't think the training wheels is a good analogy, since those are
quite inflexible and externally imposed. In effect, it's an imposed
limitation (for safety) but without any changes to the bicycle itself
to let you define the world such that the safety is in context.
Unfortunately, I can't come up with a counter analogy at the moment.
> True, I don't know jack about Ada. I don't know jack because I've never
> known anyone (other than yourself) who claims to use it. This doesn't make
> it a bad language, just an impractical one. (...)
I don't think that can be a blanket statement - as with any language
it may be better suited to some venues than others. I'm sure in many
circles most of the languages discussed here (including Python itself)
could be considered impractical, and in some of those areas (e.g.,
embedded systems) Ada is more likely to shine. And I'm not sure that
practicality in a language is a prime requisite for its use in a
learning environment.
> I think Ada had its chance and failed to claim enough interest to make it
> relevant today.
Even were it not in use at all (which it is, although certainly not as
prevalent in the open source areas), I think Ada as a language is
still relevant for those interested in languages (which is sort of
on-topic for this learning thread). It contains a lot of interesting
language features (its type system, packages, tasking model for
example). And much as Pascal might have been used in introductory
classes a while back, I would think that Ada could serve the same
purpose while not being subject to Pascal's limitations.
Clearly though, Ada is not in use to the extent of something like
C/C++, and that makes it harder to try to introduce in environments
where people are unfamiliar with it.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
David Bolen
> Cliff writes -
>
> >One of Python's strengths is that almost every
> >line of code is related to solving the programmer's
> >goal rather than telling the compiler how to
> >compile the code.
>
> Which has been my experience, and why I think
> I was more successful with Python than with
> other languages I false-started with before I
> came to it.
>
> In effect, my interest was not in learning
> programming, but in accomplishing some things
> for which an understanding of programming
> happens to have been an essential.
I agree, and also find this aspect of Python very seductive and
addicting. Of course, outside of the learning environment, it does
carry a penalty - typically performance, since it's accomplished by
pushing most everything to dynamic runtime.
So there's likely always to be room for languages that provide more
details at compile time to the compilers, and I think that being
exposed to that fact, and that manner of thinking, would also be
helpful in an introduction to programming.
Then again, some of the functional languages (such as the ML-based
ones) seem to do a really nice inference job to get back a lot of
performance without much declaration.
David Andreas Alderud
> design - I'm not here simply to disagree! I presume you mean strawman,
> stoneman, ironman? OK, but in that case how come there had to be a "next
> version"? Clearly all that up-front design didn't produce a perfect
> language. How is this different (except perhaps in terms of gestation
time)
> from other standardised languages?
Naturally, there is no such thing as a perfect language, because the
perception of people are different, and changing with time.
The design changed when OO became the thing on everyone's lips, just like
components are today, but adding components to a language is simple, OO is
not. (Though it is quite simple to write OO code in a non-OO language.)
There is some strong doubt about the need of OO in Ada, but now it's part of
the standard so there no point in complaining about it.
> Well you surely don't believe that *buildings* are built exactly as they
are
> conceived? Why else do the construction teams have to supply "as built"
> drawings - because they have to modify the building design as construction
> progresses, to take into account the practical considerations of the site,
> materials, etc.
No, of course not. But I recommend that you read books on architectures by
members of the Go4 or the simpler ISBN 0-201-69967-2 to understand what I'm
trying to say.
> Software is difficult precisely because it is so malleable, and so a
design
> can evolve. This is both a good and a bad thing. But none of this really
has
> to do with suitability as a teaching language, and I still don't see Ada
as
> any better for teaching purposes than Python.
You could read my reply to Laura for more information.
David Andreas Alderud
> department at his university isn't exactly the best one in Sweden (hardly
> his fault), but he has a point there: Ada wasn't just designed once, but
> twice.
True, MSI is not prominent, on the other hand, there is no CS apartment in
Sweden that is worth jack.
In fact, I'd say it's hard to find any university that does anything special
these days, though I'd cut my arm off to be teached by Aho, Ullman, McIlroy,
Rabin etc.
Though in MSI's defence, Ritzau's Java technology is considered state of the
art, 1.4 is largly based on his work I have heard.
> unlike e.g. Scheme, which we all know was discovered, not designed.
Though LISP is neat, since it's so darn easy to implement, I wouldn't
stretch it as far as call it well designed syntax-wise.
Scheme is no different, parathesis mania is hardly good design, ask anyone
what they think of writing 30kLoC+ programs in LISP.
On the other hand, wouldn't call anyone that has not written 30kLoC+
programs a real programmer.
> (and we all know that the van Rossum's don't know anything about
> design ;-)
Non-declarative languages are not following good design patterns, though in
all fairness I love the Python implementation and its fast prototyping
abilities.
Now repeat after me: "Non-declarative is bad!"
Jeff Shannon
David Andreas Alderud wrote:
> Yes, but then, aren't we supposed to teach programmers how the computers
> work? Or am I just a relic of the ancient world of bits, shifts and
> rotations.
Except that, the whole idea of CP4E and teaching programming languages to all
(or most) schoolchildren, is that most of these students will *never* become
programmers. They will do other things, but will benefit from having some idea
of how to program a computer. Programmers will still need to know the details
of how a computer works, but they'll pick that up later on (as they learn other
languages, and advanced data structures, and so on).
But to the person who's just trying to write a script to, say, generate a
catalog of all the mp3 files on his computer, it really doesn't *matter* how
many bits a given integer requires, or the difference between a simple linked
list and a red/black tree, or...
To use an automotive analogy, we're teaching kids to be able to change the oil
on their computers, not how to rebuild the transmission. :)
And even if they later go on to learn how to rebuild that transmission...
they'll still benefit from already knowing how to change the oil.
Jeff Shannon
Technician/Programmer
Credit International
Neil Hodgson
> I love Python, I advocate it a lot, but I believe that Ada95
> is the prime language for beginners.
I was an Ada83 programmer (on a non-military project) and I don't think
its a good language for beginners. Ada is too large to be fully understood
within a reasonable time. Type based overloading is very complex to
understand and predict. The task feature was particularly troublesome as it
did not map onto other well established multi-tasking models. Ada95 looks
even more complex with one core language and 10 optional annexes.
Ada's strict typing goes too far adding much noise to basic operations if
used to define all variables with appropriate constraints. Eventually
programmers give up on this and start using the simple basic types instead.
Use appears to have contracted to just military projects here, most
commercial users dropping it for C/C++ to increase productivity.
Neil
Jeff Sandys
>
> ... (The Logo Foundation):
> http://el.www.media.mit.edu/groups/logo-foundation/
If you go to the products / software page you will
find free versions of Logo at the bottom of the page.
I recommend UCBLogo for the PC, (dos or windows), mac,
(68xxx or powermac) and c source for unix. It features
a lambda function and macros with other advanced features.
The distribution includes documentation, help files and
the Jove (a mini emacs) editor. There is also a Logo
mode available for emacs. It is under the GNU license.
MSWLogo is a full up windows version of UCBLogo and it
includes access to some windows widgets.
Elica is a Logo dialect with object extensions.
StarLogo is written in Java, runs on power macs and
windows. Each turtle and background cell can be
programmed, new turtles and cells can have inheritance.
It is useful for cellular automata and system simulations.
Thanks,
Jeff Sandys
Fredrik Lundh
> I see big demand for Ada programmers here in Sweden, not as big as Java and
> C++, but indeed much more so than Python :)
Says who?
If you're judging the demand by studying job ads, you should be
aware that light-weight tools like Python and Perl are often hidden
under labels like "various scripting languages" or "rapid development
tools" or "script programming".
Most companies don't mention them at all, even if they use them
a lot. Why would they? Any programmer worth hiring can pick up
a light-weight language in a day or two.
</F>
Cliff Wells
> I see big demand for Ada programmers here in Sweden, not as big as Java and
> C++, but indeed much more so than Python :)
> Airbus in France use Ada almost exclusivly, if my friend who works there is
> correctly informed.
Now you've done it. The list has been dead for over an hour. I can only
assume everyone is moving to Sweden to learn Ada.
--
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308
David Andreas Alderud
> aware that light-weight tools like Python and Perl are often hidden
> under labels like "various scripting languages" or "rapid development
> tools" or "script programming".
Those are not specific Python programming jobs.
> Most companies don't mention them at all, even if they use them
> a lot. Why would they? Any programmer worth hiring can pick up
> a light-weight language in a day or two.
True, but those are just programming jobs, not specific Python programming
jobs. Any programming language is good to know about when starting a job, so
fear the ancient might of COBOL!
Dr. David J. Ritchie, Sr.
"Dr. David J. Ritchie, Sr." wrote:
> With regard to your question and general topic...
>
Well, I don't want to take issue with anyone so I'll
just reply to my own post.
What I'd like to report based on my own experience
of having done multi-week programming sessions
for Middle School kids at three different Middle
Schools for three years are the following items.
I have learned that they are important factors for
success in my teaching of computer programming
to Middle School Students--particularly as a volunteer.
* It's important to figure out how what you want to
do with teaching programming connects to the
>existing< curriculum.
For example, I learned that the existing curriculum is
the product of many years of development by
collaborations of teachers in the school district. It
is very hard to get any long term involvement if
you can't give the teacher a line of reasoning that
goes from the existing curriculum to "and so we are
teaching x or y or z in computer club".
* It's important to understand what the typical
distribution of readiness is in the age group at
the school where you propose to teach the subject.
For example, I learned that the students I had would
have quite a range of skills in keyboarding and
accurate typing. I also learned that the students would
have quite a range in their understanding of abstract
concepts (like what is an algorithm). I learned that
they would do better at internally developing that
understanding if they were walked through a set
of tasks which exemplified that than if they were talked
to about the concept.
*It's important to match the approach of your teaching
the subject to those readiness factors.
For example, I changed from having the students
type the three line exercise into the computer to
having it all there already for them to use and then
asking them to make small changes in it. I also
changed from a textbook approach where I talked to
them about concepts to a do it approach where they
were asked to do a recipe and then asked questions
about it afterwards. In the doing of it almost even
in rote drill, I found that they would internally come
to some level of an understanding about what was
behind what they were doing. In some cases, I would be
rewarded by the "Aha, I see" from the student. In other
cases, they would just have fun and I learned to take that
as sufficient accomplishment of >their< goals (appropriate
for a club of course--may be different if you have your course
locked into a curriculum which downstream courses are
expecting to have the students know.)
*Finally, it's important to be humble when approaching
a teacher, computer learning center staff person, or administrative
person.
For example, I learned I had to realize that though I might think of
myself as quite an expert in X or Y or Z, there were a lot of
other factors involved in getting something up in running
like making sure it didn't get in the way of the existing
teaching of the existing curriculum and the running of the
school. I learned also that it is important to partner with a
teacher who has a lot of class room experience and >>listen<<
to that individual when they express their opinion about
something and, at the outset start by assuming that they are
probably right, and then figure out how to move towards
whatever it is that they are suggesting. I found that the
teachers were a lot more subtle in their suggestions than
I was used to experiencing in my professional work (i.e.,
they didn't exactly strongly confront you
like I was commonly used to) and that it required a lot
of care on my part to tune in and react and adapt in order
to make the partnership work.
With those factors addressed in the described manner,
I have been able to do a computer club program as
detailed on my web site over several years time.
(See http://home.mindspring.com/~djrassoc01/ )
--David
P.S. This is Naperville School District 203 whose
8th graders were top-ranked in the world on the
TIMMS test.
--
Dr. David J. Ritchie, Sr.
djras...@mindspring.com
http://home.mindspring.com/~djrassoc01/
David Andreas Alderud
> its a good language for beginners. Ada is too large to be fully understood
> within a reasonable time. Type based overloading is very complex to
> understand and predict. The task feature was particularly troublesome as
it
> did not map onto other well established multi-tasking models. Ada95 looks
> even more complex with one core language and 10 optional annexes.
Where you tought Ada prior to this? Most people with negative image of Ada
got off on the wrong foot, which, of cource, is true for everything.
Ada83 had only 63 reserved words, Ada95 has only 68. Thougt in all fairness
Python only has 28.
Task are extremly simple and powerful, they work excelent in multitasking
envirionment; tasks are like threading and any user, including the
beginners, can use tasks if they can use packages, which they can if they
ever printed anything to the screen.
> Ada's strict typing goes too far adding much noise to basic operations
if
> used to define all variables with appropriate constraints. Eventually
> programmers give up on this and start using the simple basic types
instead.
I've found this to be very flexible, maybe you're school with C and that
caused problems?
> Use appears to have contracted to just military projects here, most
> commercial users dropping it for C/C++ to increase productivity.
Strange since in every report I've seen on productivity Smalltalk wins and
Ada in general is on a strong second place, C++ productivity is generally
considered to be 1/6:th or lower of Smalltalk for example.
Paul Winkler
<aal...@student.remove-this-part.vxu.se> wrote:
>Strange since in every report I've seen on productivity Smalltalk wins and
>Ada in general is on a strong second place, C++ productivity is generally
>considered to be 1/6:th or lower of Smalltalk for example.
Anybody done such studies with python in the list? I'm curious how it
would fare. (Of course I want to think it would rate very highly...)
--PW
Andrew Dalke
>Anybody done such studies [of software development productivity]
>with python in the list? I'm curious how it would fare.
Quoting from the Python language comparison page at
http://www.python.org/doc/Comparisons.html
] Lutz Prechelt wrote "An Empirical Comparison of C, C++, Java,
] Perl, Python, Rexx, and Tcl for a Search/String-Processing Program
] in which he compares productivity and program performance for 80
] different implementations of the same requirements, in 7 languages.
The referenced URL is
http://wwwipd.ira.uka.de/~prechelt/Biblio/#jccpprtTR
Andrew
da...@dalkescientific.com
Neil Hodgson
> Where you tought Ada prior to this?
No, although I had read articles and the book by I.C. Pyle while at uni.
> Task are extremly simple and powerful, they work excelent in multitasking
> envirionment; tasks are like threading and any user, including the
> beginners, can use tasks if they can use packages, which they can if they
> ever printed anything to the screen.
The team were either used to OS mediated tasking (like me) or to bare
machines writing their own interrupt based code. We were familiar with low
level IPC based on semaphores and shared memory and higher level techniques
like queuing. Most of the IPC in the systems could be sensibly designed
using message queues. Ada's rendezvous is both higher level and more
expensive then the lower level techiques and less expressive than higher
level techniques. So you get to build a message queuing package on top of
rendezvous which is extra work and runs into the need for strict typing
which conflicts with most links between tasks needing to send many types of
message.
To contrast, part way through the project we moved to a newer platform
for the UI subsystems (written in C) which provided threading as well as the
heavy-weight processes previously used for the UI. Threads were quickly and
easily assimilated, being used to improve responsiveness.
> I've found this to be very flexible, maybe you're school with C and that
> caused problems?
I went to a fairly conventional university that used Pascal as the
primary teaching language although C (and FORTRAN, COBOL, lisp and awk) were
given some time. Strictly statically typed languages have their place but I
see that being in libraries of low-level code managed by script code and not
for initial learning which should be about achieving outcomes.
> Strange since in every report I've seen on productivity Smalltalk wins and
> Ada in general is on a strong second place, C++ productivity is generally
> considered to be 1/6:th or lower of Smalltalk for example.
Defence contractors are forced to use Ada, companies that have a choice
generally don't. Ada is not a bad language but for any given project I would
be able to choose a language that IMO is superior to Ada. For low-level
projects, that would be C++.
Neil
Arthur Siegel
>Except that, the whole idea of CP4E and teaching programming languages to
all
>(or most) schoolchildren, is that most of these students will *never*
become
>programmers. They will do other things, but will benefit from having some
idea
>of how to program a computer. Programmers will still need to know the
details
>of how a computer works, but they'll pick that up later on (as they learn
other
>languages, and advanced data structures, and so on).
>But to the person who's just trying to write a script to, say, generate a
>catalog of all the mp3 ...
The problem with this slant is that there is little justification to bring
the
necessary resources to bear for "teaching programming languages to all
(or most) schoolchildren" if the end result is scripts cataloging mp3s.
If the end result is a deeper appreciation of math concepts, scientific
concepts,
etc. - much educational productivity can be leveraged, given students
with just some fundamentals under their belt. But I think we are missing
the
CP4E boat when we focus on one hand on training computer scientists
starting at age 12, or, on the other, believing that the educational value
of
the context of the programming-related curriculum is not of the essence.
Art
Arthur Siegel
Paul Rubin
> The problem with this slant is that there is little justification to
> bring the necessary resources to bear for "teaching programming
> languages to all (or most) schoolchildren" if the end result is
> scripts cataloging mp3s.
>
> If the end result is a deeper appreciation of math concepts,
> scientific concepts, etc.
I think a big goal of the Mindstorms crowd is teaching the concept of
debugging. Most skills are taught with the idea that you master
something by learning it well enough to do it perfectly, so if you
make a mistake at it you haven't learned the skill yet. Teaching
programming to young kids is supposed to develop the cognitive skill
of diagnosing and correcting errors. That's more fundamental than
"applications" like cataloging mp3's or even understanding math
concepts.
Brian Elmegaard
> "Dr. David J. Ritchie, Sr." wrote:
>
> > With regard to your question and general topic...
> >
>
> Well, I don't want to take issue with anyone so I'll
> just reply to my own post.
David, I have read this and your first reply with interest. Thanks for
the input.
--
Brian (remove the sport for mail)
http://www.rk-speed.dk http://fiduso.dk http://sunsite.auc.dk/dk-tug
\TeX, tak.
Brian Elmegaard
> The problem with this slant is that there is little justification to bring
> the
> necessary resources to bear for "teaching programming languages to all
> (or most) schoolchildren" if the end result is scripts cataloging mp3s.
Math is taught even though everyone doesn't have to be a scientist.
My original question was based on that I think that with an easily
written and understood, running pseudo code language, learning
programming may be much easier.
> CP4E boat when we focus on one hand on training computer scientists
> starting at age 12, or, on the other, believing that the educational value
> of
> the context of the programming-related curriculum is not of the essence.
Good point but I believe the problem can be handled.
Duncan Booth
news:8ef9bea6.01110...@posting.google.com:
> How soon does a beginner run into the following problem? (see also the
> "How much is set in stone?" thread)
>
> #------------------
> flag = 0
>
> def f(x):
> flag = 1
> return 2*x
>
> y = f(3)
> print y, flag
> #------------------
> output:
> 6 0
>
<snip>
> (2) After being shocked by the above example, students start to put
> 'global' statements in every single function for every single
> variable. They don't understand what is going on, they just don't want
> to be bitten by the same bug, again.
So perhaps the students should be taught not to use the global statement at
all in situations like the one above:
def f(x):
return 2*x, 1
y, flag = f(3)
And if they need to store state, it may be time to introduce classes:
class F:
def foo(self, x):
self.flag = 1
return 2*x
f = F()
y = f.foo(3)
--
Duncan Booth dun...@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
Laura Creighton
> I think a big goal of the Mindstorms crowd is teaching the concept of
> debugging. Most skills are taught with the idea that you master
> something by learning it well enough to do it perfectly, so if you
> make a mistake at it you haven't learned the skill yet. Teaching
> programming to young kids is supposed to develop the cognitive skill
> of diagnosing and correcting errors. That's more fundamental than
> "applications" like cataloging mp3's or even understanding math
> concepts.
In the same vein, if any of you out there are writing (or revising)
'how to program in Python' books or papers, could you please put
the section on exception handling _early_, say, right after 'what
is a loop', rather than in the last chapter? I've decided that what
my brother's great insult program needed was:
a) 1, possibly 2, dictionaries
b) 1 loop
c) exception handling for bad data
(and, of course, a lot of insults. Data collection is an
important part of the scientific process...)
One of the nice things about programming is that you _can_ just try
it and see. Here's the intepreter. Go play. If it blows up, nothing
particularily bad can happen. But a great many new posters here
need to be _TOLD_ that. They _ask_ 'What would happen if I typed ...'
rather than just typing it. Clearly, they come from a background
where making mistakes is a much more serious business than just
getting a ValueError. I can't prove it, but I suspect that our
societies would be more fun to live in if more people, from an early
age, were taught how to clean up after things got unexpectedly messy,
and how to predict the sorts of messes that were inherant in any
situation. There are days I feel that I am living in the section
of code marked /* CAN'T HAPPEN */.
Laura Creighton
Michael Hudson
> Paul Rubin writes:
> > I think a big goal of the Mindstorms crowd is teaching the concept of
> > debugging. Most skills are taught with the idea that you master
> > something by learning it well enough to do it perfectly, so if you
> > make a mistake at it you haven't learned the skill yet. Teaching
> > programming to young kids is supposed to develop the cognitive skill
> > of diagnosing and correcting errors. That's more fundamental than
> > "applications" like cataloging mp3's or even understanding math
> > concepts.
>
> In the same vein, if any of you out there are writing (or revising)
> 'how to program in Python' books or papers, could you please put
> the section on exception handling _early_, say, right after 'what
> is a loop', rather than in the last chapter?
That's what my tech review for one such said over the summer :) This
may have been too late, of course.
But Laura is right here. Very very right.
Cheers,
M.
--
First time I've gotten a programming job that required a drug
test. I was worried they were going to say "you don't have
enough LSD in your system to do Unix programming". -- Paul Tomblin
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
Wesley J. Chun
"Teaching Python (programming) to Teachers"
Kids are young, flexible, and easily impressioned, so teaching
kids isn't the only topic involved with this subject. In order
to make kids' learning effective, it must also come with the
supporting infrastructure, meaning teachers and courseroom
materials.
We must first teach the teachers! They will be the ones who are
passing on this knowledge to our children, and so that should be
the first step. We cannot take it for granted that all teachers
are like Jeff E., Sheila K., or Tim W. :-) If we can achieve
this, that will facilitate learning on a more effective level.
I wonder if there are any such technology training requirements
for those going after teaching credentials in a math/science
discipline. Anyone know?
Anyway, I have proposed a continuing education course for teachers
which has a goal of teaching teachers the basics of programming
(using Python of course) to those who have little or no background
in programming at all. I made this pitch to UC Santa Cruz out on
the California central coast and at this time, is currently under
review. I have not made this proposal elsewhere yet, as i also
have a full-time job! :-)
Finally, there has to be effective teaching materials for the
classroom, both for teachers and for students. Concepts must be
taught at the same time as "language syntax." The more effective
programming languages are those, of course, whose syntax does NOT
get in the way of learning the concepts. Python, Scheme, and BASIC
are some of the better choices in that area. And like some of the
other postings i've seen, you DON'T have to reveal *everything*
that Python has to offer. just start with a small subset and move
from there.
anyway, those are my $0.02 for now.
-wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
"Core Python Programming", Prentice Hall PTR, December 2000
http://starship.python.net/crew/wesc/cpp/
wesley.j.chun :: we...@yahoo.com
cyberweb.consulting :: silicon.valley, ca
http://www.roadkill.com/~wesc/cyberweb/
John Roth
"Michael Hudson" <m...@python.net> wrote in message
news:u4ro4n...@python.net...
> Laura Creighton <l...@strakt.com> writes:
>
> > Paul Rubin writes:
> > > I think a big goal of the Mindstorms crowd is teaching the concept
of
> > > debugging. Most skills are taught with the idea that you master
> > > something by learning it well enough to do it perfectly, so if you
> > > make a mistake at it you haven't learned the skill yet. Teaching
> > > programming to young kids is supposed to develop the cognitive
skill
> > > of diagnosing and correcting errors. That's more fundamental than
> > > "applications" like cataloging mp3's or even understanding math
> > > concepts.
> >
> > In the same vein, if any of you out there are writing (or revising)
> > 'how to program in Python' books or papers, could you please put
> > the section on exception handling _early_, say, right after 'what
> > is a loop', rather than in the last chapter?
>
> That's what my tech review for one such said over the summer :) This
> may have been too late, of course.
>
> But Laura is right here. Very very right.
Then possibly the decision to make exceptions classes was
wrong from a tutorial veiwpoint? Technically, it was the
right decision, but it does shove exception handling rather
late, after classes have been introduced.
John Roth
Jeff Shannon
John Roth wrote:
Not necessarily. Unless you're defining your own exceptions, you don't have
any reason to care whether they are strings or classes or transfinite
cardinals. ;) A beginner doesn't need to know what a ValueError is, they
just need to know how to catch it, and when to expect it. The main
practical effect of using classes, is that you can catch a variety of
exception types by catching a base class, but I don't think this feature is
essential to beginners. By the time you're ready to exploit that
polymorphism, you should be ready to understand classes and inheritance
anyhow. (My $0.02, anyhow...)
Arthur Siegel
>I think a big goal of the Mindstorms crowd is teaching the concept of
>debugging. Most skills are taught with the idea that you master
>something by learning it well enough to do it perfectly, so if you
>make a mistake at it you haven't learned the skill yet. Teaching
>programming to young kids is supposed to develop the cognitive skill
>of diagnosing and correcting errors. That's more fundamental than
>"applications" like cataloging mp3's or even understanding math
>concepts.
Again, IMO - the acceptance of programming instruction incorporated
somehow into core curricula is up against enough - without making
its acceptance dependent on the acceptance of some particular educational
theory/philosophy.
Let's accept that learning math, for example, is a good thing, and
demonstrate an enhanced curricula incorporating some programming
that will accelerate and deepen that process. "The cognitive skill of
diagnosing and correcting errors" might in fact be more fundamental
(and important) than understanding math concepts - who am I to
argue with the MindStorms crowd. I will tell you that to the untrained
ear, it sounds like horeshit. Which is the point, because those of us
serious about seeing some progress made are not willing to wait
until the rest of the educational world happens to see the light
on this and similar points.
Art
Cliff Wells
> ear, it sounds like horeshit. Which is the point, because those of us
> serious about seeing some progress made are not willing to wait
> until the rest of the educational world happens to see the light
> on this and similar points.
Teaching Python to children? Sounds like you're working hand-in-glove with
the PSU. You can't possib
Paul Rubin
> Again, IMO - the acceptance of programming instruction incorporated
> somehow into core curricula is up against enough - without making
> its acceptance dependent on the acceptance of some particular educational
> theory/philosophy.
>
> Let's accept that learning math, for example, is a good thing, and
> demonstrate an enhanced curricula incorporating some programming
> that will accelerate and deepen that process. "The cognitive skill of
> diagnosing and correcting errors" might in fact be more fundamental
> (and important) than understanding math concepts - who am I to
> argue with the MindStorms crowd. I will tell you that to the untrained
> ear, it sounds like horeshit.
In the Mindstorms situation, we're talking about very young kids, like
age 6-8 or so. Normally nobody thinks of kids that young as needing
"programming instruction" or training in software development. Here's
an article from Papert's website about it called "Tomorrow's
Classrooms", that gives a sense of what he wanted to accomplish:
http://www.papert.org/articles/TomorrowsClassrooms.html
Basically he was trying to follow up the ideas of Jean Piaget, the
child development researcher. Perhaps the ideas are horseshit, but
Time Magazine apparently didn't think so--it printed Papert's article
on Piaget in its special issue on "The Century's Greatest Minds".
Peter Hansen
>
> Python is without doubt a very good language, but it's not good for the
> beginner because they will pick up bad practices, mostly because of the
> loose type paradigm.
This, of course, represents a value judgment on your part that loose
typing (and by the way, Python is *strongly* typed, but dynamically so)
is a bad thing. In any case I would argue that the habits beginners would
pick up learning Python would serve them well in the future. When they get
to a statically typed language, or a weakly typed one (Python is neither),
they will question *its* value and ease of use.
> For teaching programming I strongly belive that Ada95 is by far the best, it
> teaches the students how to write good code;
No, good teachers who promote consistent coding style, modular
design, unit testing, and so forth teach students how to write good code.
The language has very little to do with it, except insofar as some
languages get in the way of that, while others do not. Python does not.
> I do believe that at least in
> universities Python should be the language of choice beyond the first year
> studies, unless doing hardware or AI programming.
Python has proven very effective for hardware programming. Yes,
via a DLL or driver or something, but then again very little of
what constitutes "hardware programming" involves access to the
hardware, and most involves what you *do* with that access.
AI programming is apparently best done with LISP according to
some, but I've found Python nice for, say, genetic algorithms,
so I wouldn't say it represents a necessarily *bad* choice.
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
Peter Hansen
> "Michael Hudson" <m...@python.net> wrote:
> > Laura Creighton <l...@strakt.com> wrote:
> > > In the same vein, if any of you out there are writing (or revising)
> > > 'how to program in Python' books or papers, could you please put
> > > the section on exception handling _early_, say, right after 'what
> > > is a loop', rather than in the last chapter?
> >
> > That's what my tech review for one such said over the summer :) This
> > may have been too late, of course.
> >
> > But Laura is right here. Very very right.
>
> Then possibly the decision to make exceptions classes was
> wrong from a tutorial veiwpoint? Technically, it was the
> right decision, but it does shove exception handling rather
> late, after classes have been introduced.
I wouldn't think one needs to understand classes to be able
to use exceptions effectively. They just look like a simple
name for a type of problem that could occur in a block of
code, and one only needs to learn a little syntax to be
able to use them to great effect.
Paul Winkler
>I wouldn't think one needs to understand classes to be able
>to use exceptions effectively. They just look like a simple
>name for a type of problem that could occur in a block of
>code, and one only needs to learn a little syntax to be
>able to use them to great effect.
That's exactly how I experienced them when I first learned python. I
didn't even know I *could* define my own exceptions for a while. I
got a lot of work done just by thinking of them as "errors you can
catch and / or deliberately raise."
- Paul Winkler
Arthur Siegel
> Normally nobody thinks of kids that young as needing
>"programming instruction" or training in software development.
Then remind me again how it came up in the context of this
thread?
>Here's an article from Papert's website about it called "Tomorrow's
>Classrooms", that gives a sense of what he wanted to accomplish:
> http://www.papert.org/articles/TomorrowsClassrooms.html
Reminds me very, very much of an article I read in the Linux Journal
a while back, that wasn't about Python, but was in a supplement devoted
to it.
>Basically he was trying to follow up the ideas of Jean Piaget, the
>child development researcher.
That's great for the folks who don't happen to think Piaget is
at some level horseshit. Happily, a programming language
need not take a position - unless it for some reason chooses to.
My deepest objection - and why I'm consistently nasty when
getting near this subject - is that it always seems to be the tool in play
< LOGO/MindStorm/Alice, etc and etc> and its creators/advocates
that are hogging center stage. And off in the corner somewhere is
the happy student, and somewhere backstage, a subject matter.
God, I'm tired of going around in this circle.
Art
Paul Rubin
> That's great for the folks who don't happen to think Piaget is
> at some level horseshit. Happily, a programming language
> need not take a position - unless it for some reason chooses to.
Piaget's work is considered mainstream and valid these days. I
suppose there are people who think it's horseshit, but there are also
some who think the earth is flat.
> My deepest objection - and why I'm consistently nasty when
> getting near this subject - is that it always seems to be the tool in play
> < LOGO/MindStorm/Alice, etc and etc> and its creators/advocates
> that are hogging center stage. And off in the corner somewhere is
> the happy student, and somewhere backstage, a subject matter.
I don't think Papert had any particular agenda to use Logo. Logo was
just a vehicle that he had available. He could just as happily have
used something else if he had it.
Sheila King
wrote in comp.lang.python in article
<mailman.1005371293...@python.org>:
:My deepest objection - and why I'm consistently nasty when
:getting near this subject - is that it always seems to be the tool in play
:< LOGO/MindStorm/Alice, etc and etc> and its creators/advocates
:that are hogging center stage. And off in the corner somewhere is
:the happy student, and somewhere backstage, a subject matter.
:
:God, I'm tired of going around in this circle.
If you were in the classroom working with students, this wouldn't be
important at all.
At least, for me, it never was. In a way, it is nice for people to be
out there expounding on their pet theories and pet methods. At least if
they are vocal enough about it, the educator may become aware of them,
and hopefully several alternatives. Then it is up to the educator to
decide what to implement in the classroom.
For years I taught AP Calculus, and the "reform" and "graphing
calculators" are all the rage, and proofs are down, and algebraic
manipulation is down. But I listened to all of this. I got copies of the
reform textbooks. I participated in the mailing lists on this topic. I
went to the workshops and conferences.
And then I went off, alone, to my own corner, and decided what, if any,
of this stuff I wanted to incorporate into my course, and how I wanted
to present the material in my classroom.
I don't see why this "circle" would bother any classroom practitioner at
all. Because teachers really do get to decide what they want to do, to a
large extent, when they go into their classroom with their students and
close the door.
--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/
GerritM
possibly the decision to make exceptions classes was
> wrong from a tutorial veiwpoint? Technically, it was the
> right decision, but it does shove exception handling rather
> late, after classes have been introduced.
>
> John Roth
I didn't even realize exceptions are classes until reading this message... I
am using Python for more than one year now and did not need this knowhow at
all, even not when using exeptions.
Regards Gerrit
Arthur Siegel
>suppose there are people who think it's horseshit, but there are also
>some who think the earth is flat.
Then maybe I just need change my strategy.
Everything I say is also based on Piaget - retroactively.
>I don't think Papert had any particular agenda to use Logo. Logo was
>just a vehicle that he had available. He could just as happily have
>used something else if he had it.
What might he come up with using out-of-the-box Python,
maybe a 20 line underlying module, and a text editor?
Probably plenty. Truely succinct and Pythonic.
It always seem to me that *I* am being
the Python advocate in these discussions - and fighting
something uphill within the Python community
in being so. Confusing.
Art
Laura Creighton
> I don't see why this "circle" would bother any classroom practitioner at
> all. Because teachers really do get to decide what they want to do, to a
> large extent, when they go into their classroom with their students and
> close the door.
I have a problem. I can't pick the _students_ that come into my
classroom. And wherever I have come across a student that learned
calculus from the graphing-calculator school, I have found somebody
who does not understand, really understand, what 'this function is
increasing' _means_. They are incapable of doing their own visualization
of that. Fortunately for me, I don't run into these people that often.
But they are crippled, so much that it shows. It is evident in trying
to have the simplest of conversations with them. They have little or
no mathematical intuition at all.
So either a) the method is bad, and cripples minds (period) or
b) the method, if not taught according to some vigorous standard and
in conjunction with some other methods, cripples minds (or doesn't
allow them to expand properly). (For purpose of argument only I am
willing to believe that _somewhere_ it is working.)
If the second is the case, then high school teachers must not be
allowed to pick and chose what to do, because with the best intentions
in the world they will produce a program that will produce people are
mathematically naive. Which is my experience. We have people who
never made the leap from arithmetic to mathematics. They are human
calculators, tied to machine calculators, but have no mathematical
intuition whatsoever, and a great difficulty in thinking abstractly.
It is frightening. They do get correct answers, as long as their
calculators have batteries, but they can't understand them.
One must never design educational policy thinking only how the best
teachers will educate the most exceptional students (exceptionally
good or exceptionally poor.) The policy must instead focus on the
worst third of teachers. This is hard on the gifted teacher, indeed,
but the alternative is hard on _everybody_.
Laura Creighton
Arthur Siegel
>students, this wouldn't be important at all.
Not sure what you are saying.
According to Paul, Piaget (and anything that invokes
the name) is a done deal.
But, perhaps its more that the folks who see it otherwise
just got exhausted counter-arguing.
Maybe teachers need to be exposed to some counter din.
I volunteer.
Art
Sheila King
wrote in comp.lang.python in article
:Sheila King:
:> I don't see why this "circle" would bother any classroom practitioner at
:> all. Because teachers really do get to decide what they want to do, to a
:> large extent, when they go into their classroom with their students and
:> close the door.
:
:I have a problem. I can't pick the _students_ that come into my
:classroom.
Same here. Well, when I taught AP courses (Calculus and Computer
Science), I did have some say in what student could take the course. But
that was an exception. For the other courses I taught, I took all
comers. Largely, teachers don't have any option in which students end up
in their classroom.
: And wherever I have come across a student that learned
:calculus from the graphing-calculator school, I have found somebody
:who does not understand, really understand, what 'this function is
:increasing' _means_. They are incapable of doing their own visualization
:of that. Fortunately for me, I don't run into these people that often.
:But they are crippled, so much that it shows. It is evident in trying
:to have the simplest of conversations with them. They have little or
:no mathematical intuition at all.
:
:So either a) the method is bad, and cripples minds (period) or
:b) the method, if not taught according to some vigorous standard and
:in conjunction with some other methods, cripples minds (or doesn't
:allow them to expand properly).
Well, in my opinion, the problem is in the way the previous teachers
have assessed the students, allowing them to get by with such a shallow
understanding of the topic. Whether or not the graphing calculators is
used in the course is really not the issue. The issue is: What type of
test questions was the student required to answer. The best scenario,
would be having the student take tests, at least half of the time, with
no calculator permitted, and having them answer meaty questions on the
topic. In other words: I'm not sure that the problem here is either
curriculum or method, but assessment.
:If the second is the case, then high school teachers must not be
:allowed to pick and chose what to do, because with the best intentions
:in the world they will produce a program that will produce people are
:mathematically naive. Which is my experience. We have people who
:never made the leap from arithmetic to mathematics. They are human
:calculators, tied to machine calculators, but have no mathematical
:intuition whatsoever, and a great difficulty in thinking abstractly.
:It is frightening. They do get correct answers, as long as their
:calculators have batteries, but they can't understand them.
You admit, earlier, that the number of students you've encountered who
have this shallow understanding is small, and yet you say that you want
to dictate what "high school teachers" should do.
In my experience, it doesn't matter what group you are dealing with,
whether it is teachers, doctors or plumbers, there will always be a
small part of that group that is "bad". And it really isn't reasonable
to form the policies for an entire groups based on a few "bad" ones.
:One must never design educational policy thinking only how the best
:teachers will educate the most exceptional students (exceptionally
:good or exceptionally poor.) The policy must instead focus on the
:worst third of teachers. This is hard on the gifted teacher, indeed,
:but the alternative is hard on _everybody_.
Here is what I think:
First of all, you will not eliminate the problem of bad teaching by
doing this. There will always be some bad teachers. There will always be
teachers who have their students do little or nothing and give them
passing grades. Fortunately, there are very few of these, but you will
always have them. It doesn't matter that you outline the curriculum
specifically.
Therefore, designing educational policy to "prevent" these teachers from
continuing with their bad teaching practices will not work. Furthermore,
you acknowledge that it will be hard on the good teachers, and K-12
teaching is already a shi**y job. Believe me. I just left last year
after nearly two decades. (Went from high school to college.) The
students are great. Being in the classroom is great. The
student-interaction part of the job is what it's all about. However, the
workload and the policies and all that other stuff make the job very
difficult to do. If you take yet one more thing away from the good
teachers, they will leave. Then all you will have left is the mediocre
and "bad" teachers. This will not help.
I believe that in Texas they had (and perhaps still do?) a very
lock-step math curriculum. It dictates exactly what topics will be
covered, in exactly what method, on what days, etc...
The teachers hate it. And I know from at least one source, that it has
not solved Texas' math education problems. Also, there are reading
programs (Open Court and Success For All), for elementary school with
SCRIPTED curriculum. The teachers HATE it and it is questionable that it
is an improvement. Some of the teachers I converse with (electronically)
feel that it has really lowered the bar on what the students are able to
do. (For more input on this things, visit the newsgroups
k12.chat.teacher or k12.ed.math and post a question about Open Court
Reading or Success For All, or a question about the Texas' regimented
math curriculum. Or, go to http:///groups.google.com and search the
archives of those groups. I'm sure you will find enough material to show
that the programs are not well liked and that the good teachers believe
they are actually detrimental to the students.)
About the only thing I could envision that would help, is some sort of
external exam, not written by the teacher, that the students would have
to pass. This way, the student of the poor teacher may not do well on
that exam, but at least everyone who passed that exam would have
satisfied requirements for that course. And hopefully the poor teacher
would be exposed after a short time, and removed from teaching duties.
But I can hear all kinds of complaints against this idea, too. Can you
imagine the teacher of that course, complaining (similar to your own
complaints) that it was the teachers of the previous courses, who
crippled the minds of the students he had to deal with, and that he
could not get them through the curriculum he was supposed to teach, due
to their insufficient background?
In any case, here is what I really think:
You have a problem. A few students with insufficient understanding of
the prerequisite material for your course. Instead of trying to make it
someone else's problem (dictate what the high school teachers should
do), take ownership of the problem and deal with it yourself.
Ultimately, this is what each teacher at each level should do, and it's
the only way things are going to work. At the college level: Institute
placement exams for the students, to determine their placement as
incoming freshman in an appropriate math course. And converse with the
department you work in, to put in place reasonable curriculum and
policies within your own department, so that once a student has been
correctly placed within your system, you can feel confident about their
proceeding on to the next course with sufficient knowledge.
By having placement exams, you indicate to the high school what you
require students to know to come into your program. If large numbers of
a particular school's student population are unable to pass your
placement exam, notify their administration, their district, etc... so
that they can deal with it.
Otherwise it all rolls downhill. You complain about the job being done
in the high schools. They will complain about the middle school. They
will complain about the upper elementary grades. Those will complain
about the primary grades. Nothing is accomplished but a lot of finger
pointing. Instead: Make it clear the prerequisites for your program, and
stick to them. Those students who meet your prereqs but are deficient in
a few small areas, deal with it. Remember, too, that the student bears
responsibility in all of this as well, especially after they get to
about the age of 16 or so. If you have a student in your course who
doesn't sufficiently understand the concept of increasing (and I'm sure
this was only one small example...such a student must have many other
deficiencies as well), that student MUST be aware of his/her own
deficiencies. He must be wondering why you are saying things like, "and
so we can see that..." and he is sitting there going ??? 'How can she
see that???' This should be a CLUE to the student to either ask
questions in class or come to office hours. As instructor, you should
expect to have a small number of weak students who passed the prereqs,
but only just barely, and therefore have a very shaky understanding of
the material. Unless these students take ownership of their problem and
do something about it, there is nothing that you as instructor can do
for them. So, there will be some poor grades. Oh, well.
I agree with you completely about the current situation, with students
who have a very concrete understanding of math but are unable to make
the bridge to abstractness. This has always been one of my battles in
the classroom. Currently I'm teaching two sections of College Algebra,
and these students have NO abstract thinking ability nor any ability to
set up word problems. (OK, that's a sweeping generalization. Maybe I
have a few who do have these abilities.) But this course is supposed to
introduce some abstraction, and it is like pulling them kicking and
screaming. But, I try to take care to ask questions that get at the
abstract ideas, or to disallow calculators on some of the exams and
quizzes where they might be used as a crutch (i.e. design questions
where the calculator is no advantage, or band them from the test if they
are one). At least, they will not pass the course I am teaching without
some ability to think abstractly. This is the part that is under my
control, which I can do something about.
Sheila King
wrote in comp.lang.python in article
:Sheila writes -
:>If you were in the classroom working with
:>students, this wouldn't be important at all.
:
:Not sure what you are saying.
I'm saying, that in the classroom, all the arguing about current fad
theories is a distant clamoring, that the classroom practitioner need
not deal with on a daily basis.
:According to Paul, Piaget (and anything that invokes
:the name) is a done deal.
And Paul is the one who decides? I did have to study Piaget, Dewey and
others for my credentialing courses (about 20 years ago), but the most I
could tell you about Piaget today, is that he argued that students
needed to have a concrete understanding of something before they could
proceed to an abstract understanding. As for the high school teachers I
worked with recently, I'd be surprised if even half of them could tell
you that much. In all the time I worked at the high school, I can't
remember Piaget ever coming up in discussion in the teacher's lounge, or
in one of our Math Department or Business & Technology Department or
Language Department meetings (I was members of all three departments at
various times), nor at the general faculty meetings. Maybe it did come
up, but apparently not often, nor was the mention particularly memorable
nor important, as I don't recall it at all.
:But, perhaps its more that the folks who see it otherwise
:just got exhausted counter-arguing.
To be honest, I haven't been following this whole thread. I've only read
a select few messages. But I went back and read yours and Paul's after
this post, and I'm not sure as to what the point is that is being argued
and counter-argued.
:Maybe teachers need to be exposed to some counter din.
:
:I volunteer.
If you feel you have a good point about curriculum and/or teaching
methods, put your point out there and be vocal about it. Give the
teachers access to your ideas, and the reasons why you promote it. Then
allow them to decide whether to adopt it or not.
I think that change in the curriculum should be initiated by those who
are the daily practitioners of it. Not by those sitting in
administrative offices. I was fortunate to work in a school, where at
least this much was under my control. I was allowed to choose my own
textbooks, my own curriculum, etc... That part of the job I found very
appealing. Where I worked, it was usually the "good" teachers who would
become aware of new ideas, and present them to their department. If
anything changed, it was as a result of this type of introduction of new
methods and curriculum from those good teachers. And when the
administration tried to impose top-down ideas upon us, that we did not
agree with, we fought them on those ideas, and presented our opinions
and evidence as to why we did not want to go along with it.
Laura Creighton
> Well, in my opinion, the problem is in the way the previous teachers
> have assessed the students, allowing them to get by with such a shallow
> understanding of the topic. Whether or not the graphing calculators is
> used in the course is really not the issue. The issue is: What type of
> test questions was the student required to answer. The best scenario,
> would be having the student take tests, at least half of the time, with
> no calculator permitted, and having them answer meaty questions on the
> topic. In other words: I'm not sure that the problem here is either
> curriculum or method, but assessment.
This is crazy. The problem is that the students didn't learn.
Assessing the fact that they didn't learn may help educators, parents,
and the students themselves realize that there is a huge problem, but
the question remains:
Is this a decent way to teach mathematics?
> You admit, earlier, that the number of students you've encountered who
> have this shallow understanding is small, and yet you say that you want
> to dictate what "high school teachers" should do.
Yes. The students I have met who have been exposed to this method has
also been small, foreign students mostly. What I want to dictate to
all teachers is that what they do actually promotes learning whatever
subjects they are teaching. Assesment is good for this, as a way to
evaluate the teachers, and their courses. Let us say, for argument,
that a teacher who is using method A needs to spend 4 times as much
time individually coaching students and gettting involved with them
personally than a person using method B. Then only teachers who are
also willing to make the commitment to spend the 4 times as much
should be using method A. And if that is only, say 10% of the
population of teachers as a whole, then method A, whatever its virtues
when taught well, must be discouraged, unless we have a way to
restrict its use to the 10% who are capable and willing to use it
effectively. Its wholesale adoption means society as a whole suffers,
and, in the aggregate, statistically speaking, students as a whole are
being more poorly taught.
This really stinks for the teachers in the 10%, and their students,
but the alternative really stinks for everybody else.
> In my experience, it doesn't matter what group you are dealing with,
> whether it is teachers, doctors or plumbers, there will always be a
> small part of that group that is "bad". And it really isn't reasonable
> to form the policies for an entire groups based on a few "bad" ones.
Yes. My suggestion was for the bottom third, not the handful of worsts.
If somebody made me _God_ I think that I would ban the bottom half of
teachers from the profession, on the grounds of our children deserving
better. I'd do that every 10 years or so, and give teachers a huge
increase in salary so that it would attract the best minds, and
the best people in general in the profession, instead of what we have
now. Until this happens, we have to design educational platforms so
that the poorest third of our educators can educate with them. There
is nothing pleasant about this at all. But I don't see being made
God any day soon, so this is the harsh reality we are stuck with.
> In any case, here is what I really think:
[much snipped. I don't live in the United States. I have no idea
if any of the mentioned programs are effective. If they are, I like
them even if all the teachers hate them. If they aren't I hate them.
What I hate worse is why you can't get rid of them already. This makes it
political, which I understand gets in the way of stopping doing bad
things because they are bad. Testing and assessing is only of use if
we can make some hard conclusions here and stop doing foolish things.]
> I agree with you completely about the current situation, with students
> who have a very concrete understanding of math but are unable to make
> the bridge to abstractness. This has always been one of my battles in
> the classroom. Currently I'm teaching two sections of College Algebra,
> and these students have NO abstract thinking ability nor any ability to
> set up word problems. (OK, that's a sweeping generalization. Maybe I
> have a few who do have these abilities.) But this course is supposed to
> introduce some abstraction, and it is like pulling them kicking and
> screaming. But, I try to take care to ask questions that get at the
> abstract ideas, or to disallow calculators on some of the exams and
> quizzes where they might be used as a crutch (i.e. design questions
> where the calculator is no advantage, or band them from the test if they
> are one). At least, they will not pass the course I am teaching without
> some ability to think abstractly. This is the part that is under my
> control, which I can do something about.
What if its too late? How old are these students? If they are in
college then it is way too late for them. You have to start developing
a mathematical intuition in childhood, and really grow one through
adolescence. You can't graft one on later, no matter how much you
would like to. It is precisely the same sort of thing as a dietary
deficiency. You correct that when you find it, but you can't undo the
stunted growth that was supposed to happen and didn't.
Why isn't this considered child abuse? Why can't we find the bad
policies at every level that cause this and stop them? Whoever in
the United States thinks that college level is the place to learn
abstraction is either a fool or a very evil person and in any
case I want him or her out of the education business. Now.
angry as anything, though not at you,
Laura Creighton