[Edu-sig] Python as a first language for computer sciencist

[Rodrigo Senra]

[ 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