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

[Kirby Urner]

> On 10/19/05, Kirby Urner <urnerk at qwest.net> wrote:
> > Technically speaking, there's no mistake here.  The coder created a
> > local variable that went out of scope.  He could always say "I meant 
> > to do that."
> 
> Well, that's the point.  Python doesn't recognize it as a mistake.
> Clearly, in my example, the programmer intended to assign a new value
> to an existing variable, rather than create a new variable.  Some
> languages make a distinction between these two concepts, so the
> language can flag this as an error.  Python doesn't make a
> distinction, and therefore, a beginner programmer (and sometimes even
> an advanced programmer) can create a semantic bug through a syntactic
> mistake, and have an extraordinarily difficult time tracking down the
> error.
> 
> This is not a desirable trait in a "first programming language" for
> teaching computer science.
> 
> --Mark

I think you've nailed a usefully generic use case in which compile time
checking of enforced declarations (of types) might save one from a common
enough type of bug: the stray typo defines some new thing into existence,
whereas the programmer meant to mention only-already-declared objects (an
intention a compiler presumably supports).

I don't believe a lack of this kind of compile time checking disqualifies a
language from being a desirable first.  Rather, we need to compensate by
emphasizing a different kind of checking:  programmer-defined checking (and
not just type checking), built around a large number of runtime tests (more
below).

> P.S.  For what it's worth, Python is the language I choose to use on a
> daily basis, because I mainly write short programs to analyze various
> puzzles I'm working on.  It's a great tool for fast and practical
> programming.  But I think it would be very hard to write a bug-free
> large-scale project in Python.  (Granted, it's hard to write a
> bug-free large-scale project in any language, but Python lacks the
> facilities for verifying even the rudiments of correctness without
> extensive run-time testing).  I'm undecided about how useful Python
> would be as an educational tool.  Seems like it has some pros and
> cons.  Since the pros have already been talked about, I thought it was
> worth bringing up one of the major cons that I perceive.

I think your input is valuable in this regard: you've described a kind of
error trapping which Python doesn't feature, plus given a sense of how
programmers have historically relied on such "spell checking" to catch
egregious, hard-to-find bugs.  

With the rise of dynamic or agile languages (not just Python), new developer
practices have gained in importance, with the eXtreme Programming (XP)
philosophy being a chief exponent of same.  Per XP, your above function
would have had a test written for it, perhaps embedded directly in its
documentation (Python supports this).  A runtime assertion should have
failed, and flagged the problem.

As Bruce Eckel likes to point out, compiler-dependent programmers often
think their job is over once the code compiles, but of course the fun has
only begun.  Runtime checks are the job of both breeds of coder.

I believe that large scale, robust Python projects manifestly exist.
They're not 100% bug free, but nor are they insufficient; they're strong
enough for whatever big important job they're doing (in many use cases).
And many satisfied customers thank their lucky stars they could get so much
for so little, given how productive good Python developers tend to be.

All that being said, yes, sometimes *Python* is NOT the right tool for the
job.  Sometimes raw machine language IS.  To say Python could be your first
(computer language) is not to say it either could or should be your last.

Kirby