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

Mark Engelberg mark.engelberg at alumni.rice.edu
Thu Oct 20 06:22:46 CEST 2005

Lots of interesting comments.

A few responses:

1.  I'm not saying that Python is infeasible as an introductory
language.  One of the things I really like about the idea of Python
for educational purposes is that you can do complex things fairly
simply, and at the end of the course, you have also learned a language
that is practical for day-to-day use.  However, I do feel that the
drawback I pointed out is a legitimate one.  It is through discussions
like this that perhaps Python or a derivative language can one day be
made an even better tool for educational purposes (although as I
understand it, there is no longer any funding for exploring an
educational-specific environment for Python).

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.  So I'm not making up this
example out of thin air.  I have seen this as a common problem (in
younger children who have limited typing experience).  I can imagine
that a different class of errors might be more prevalent in high
schoolers or college students.

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.  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.  The functional
programming academicians have made quite a bit of progress in this
direction, and I've heard some amazing stories about the robustness of
code written in a language called 001.    Nevertheless, I acknowledge
that _at the current time_, Python's design decision to gain
flexibility at the expense of additional safety checks is a reasonable
one.  But I also believe that it is possible to have our cake and eat
it too.  An ideal educational language (and perhaps the language of
the future, incorporating everything we now know about building robust
code), will have both.

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.  Is that the
pilot's fault, or the designer's?  Surely some of the blame rests with
the designer, who should design a system that takes into account the
fact that to err is human.

5.  We all carry a certain amount of baggage and bias to this
discussion.  In the interest of full disclosure, here's mine:  I
learned programming through a progression of Scheme followed by C++
(and of course dabbled in Basic and Logo as a kid).  I have tried
programming in dozens of languages, just for fun, because I love
programming languages of all breeds.  My favorite language is Dylan,
which I think best demonstrates the "have your cake and eat it too
philosophy" of providing dynamic AND static typing, object-oriented
AND functional programming styles, an interpreted interactive
environment AND native-compilation, and so on.  (Unfortunately, the
language has very little support or active development, and so it
isn't a very practical choice right now).  I think objects are
overrated, but certainly useful.  I think functional programming is
extremely powerful, but I wouldn't want to have to use it for
everything.  I use Python as my primary programming language, because
it has most of the features I want, an extremely practical set of
libraries, and a syntax and primitives that I can easily remember
(which is important because I program infrequently these days, and
don't want to have to look everything up each time I come back to
programming).  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

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 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


More information about the Edu-sig mailing list