[ Mark Engelberg ]:
> 2. My teaching experience is limited, but I did teach one programming
> class to a group of middle-schoolers. The most common mistake was, by
> far, simple misspellings of variable names (usually capitalization
> confusion). When a compiler catches this, it's no big deal. When a
> compiler reports cryptic error messages, or none at all, for such a
> common mistake, that can be a big problem.
Point taken. Even though this was not a big issue in my also limited
teaching experience, I agree that there is room for improvement.
One way to tackle the problem (when it is a problem), could be
to introduce PyChecker in the loop:
<bla.py>
def foo(bar):
x = 2*bar
y = X+bra
return x+y
</bla.py>
<output>
$ pychecker bla.py
Processing bla...
Warnings...
bla.py:3: No global (X) found
bla.py:3: No global (bra) found
</output>
This could also be improved if PyChecker suggested a *potential*
spelling mistake, drawing attention to a small edit-distance[1,2]
between
bra<->bar or x<->X. I'm not saying this *should* be added to Pychecker,
but definetely *could* ;o)
> So I'm not making up this example out of thin air.
At least from my part, there were no itentions to imply that.
> 3. I stated an opinion that I would be reluctant to use Python for a
> large-scale project. A number of people objected. It appears that
> the philosophy of the Python community (speaking in generalizations)
> can be summarized as, "We have to do runtime testing anyway, so
> there's no need for any compile-time checking." I disagree. I feel
> that every little bit helps.
Since I was one of those objecting voices, I' d like to clarify my
opinion
on this matter. The development of large-scale projects in Python is
*not*
limited by its dynamic typing nature, even though the latter does
limit what
can be solved at compile-time. But I agree with you that the amount of
compile time checking that can be done is helpful.
> And in my opinion, the future of programming will rely on highly
> intelligent compilers which ensure that the code is as correct as
> its specifications.
One lesson I learned from Python and the Python Community is that
developer happiness lies in the Zen path [3].
A highly intelligent programmer can do better with a dumb compiler, than
a dumb programmer with a highly intelligent compiler. And since we are
in the context of edu-sig, we should definetely aim for the former!
I know you agree with this, I just could not resist saying it.
> 4. Arthur felt I was suggesting that "we need to teach the
> programmers early on that they are not responsible for mistakes".
> Well, yes and no. Let's say you designed a spaceship, and put a big
> red "self-destruct" button right by the pilot's knee. You told him
> over and over again, "Remember, when you sit in the chair, whatever
> you do, don't bump the button." You train him over and over again not
> to hit the button. But then, sure enough, one day he bumps the button
> by accident with his knee, and the spaceship explodes.
I know exactly what you mean. Possible labels for the red button:
if (x=y) {...}
for(x=0;x<N;x++); {}
I' ve seen a lot of students get blown to pieces piloting C aircrafts.
> If I were to teach a class to middle-schoolers or
> high-schoolers (which I hope to do soon), Python probably wouldn't be
> my first choice (although I'd be sorely tempted). I'd probably lean
> toward Scheme for high-schoolers (the DrScheme environment is quite
> impressive from an educational standpoint), and Squeak for
> middle-schoolers. I joined this list because I genuinely want to
> engage in discussion about how to make Python more suited for
> education.
I could certainly try Scheme and Squeak in a pedagogical context.
Right now, I can give only my testimony that Python syntax and rich
library support makes it an adequate tool for introductory CS and
Computer Engineering courses. It is a much better choice than C or Java,
that are currently largely adopted here in Brazil. And I am fighting
to change
that.
> 6. I want to wrap this up with one more point that I'd love to see
> discussed here. It seems to me that ideally, an educational
> programming language should emphasize one of the dominant programming
> paradigms in a very "pure" fashion. But Python, as useful as it is,
> is anything but "pure".
"Although practicality beats purity." [3]
> Although I'm not an OO expert, I suspect that
> there are a number of features in Python that have OO-purists shaking
> their heads. And I know that Python also holds several
> disappointments for FP-purists (lack of tail recursion, for example).
> Because Python is a pragmatic hybrid approach to programming, it can
> give you some sense for OO, and some sense for FP, but I worry that
> it's not really pure enough in either respect to get to the heart of
> either.
But since Python should never be the *only* tool to be taught, when
purity
matters the teacher can fall back to the usual suspects.
best regards,
Senra
[1] http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Dynamic/Edit/
[2] http://ruby.brian-schroeder.de/editierdistanz/
[3] >>> import this
Rodrigo Senra
______________
rsenra @ acm.org
http://rodrigo.senra.nom.br
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
