Python in "math through programming" curriculum

[Alex Martelli]

"Clifford J. Nelson" <cnelson9 at gte.net> wrote in message
news:3A3EFF47.67DE69CF at gte.net...
    [snip]
> > Awhile back, Tim Peters recommended 'Concrete Mathematics'
> > (Knuth a co-author) as a good example of a "math through
> > programming" text book.  I subsequently bought it, and
> > had to agree.  So how do we "lower a ladder" to middle
> > and high schoolers starting from there?  I think Python
> > is part of the answer.
>
> I don't think Python should be a standard at all, because of
> my experience with it on the Mac. Keep the options open for
> computer programming languages.

I'm not sure what being 'on the Mac' has to do with it.
Either it's irrelevant, or you're letting platform issues
(e.g., integration with native GUI's) cloud judgment on
_language_ issues.

I'm a "multilanguage GUI" -- I strongly believe that most
software development projects (of any substantial richness
and complexity) are best served by a mixture of different
programming languages, interoperating smoothly in various
components and/or as 'glue' among those components.  Thus,
I'll hardly object to 'keeping the options open' -- indeed,
I believe smooth interoperation between different languages
is a key platform consideration (dunno what Mac has to offer
for it, and I _am_ worried that Linux is weakish in such
multilanguage-oriented infrastructure; MS is leading the
way with their '.NET' initiative, which at low levels is
ALL about multilanguage interop... let's hope it spreads!).

But you won't typically hear arguments against this from ANY
Pythonista -- Python is *ABOUT* "playing well with others"...
*designed* and *implemented* to interoperate, like only a few
other languages; most languages appear to be designed "as if"
they were to be the sole implementation language for a typical
project, with "foreign function interfaces" or the like that
sometimes look as if they were tacked on as an afterthought.
And that may be because many people disagree with my "many
languages are better than one" stance -- they'd much rather
stay monolingual, at least within a given project.


But anyway, it would not make sense to argue _against_
"making a language a standard" in one field, because other
languages may prove better at some different task, or
sub-task.  Standardization offers substantial advantages
('network externalities' in economists' parlance), and
the 'keeping open to other languages' part need not
interfere with such advantages at all.

For the specific task of "teaching some maths to middle
and high schoolers", for example, establishing some sort
of 'standard' language would have enormous benefits; and
the relevant issues are quite different from those that
would affect 'standardization upon one base language' in
other areas.  For example, issues of performance on large
real-world tasks, which are a weak point of Python (and
to a lesser extent, lazy-semantics functional languages
such as Clean and Haskell) in comparison to traditional
lower-lever languages such as C++ (and, to a lesser extent,
non-lazy functional languages, such as ML variants), and
thus provide a good part of the motivation for projects
to use multiple languages, are not all that relevant when
the task at hand is _teaching_.


On the other hand, I think an issue of crucial importance
is 'paradigm choice'.  Some languages espouse a specific
programming paradigm very strongly: it would make little
didactical sense to use C for functional or O-O programming,
for example -- or Haskell for anything BUT (lazy-centered)
functional programming, or Smalltalk (or Java) for anything
BUT O-O programming, &c.

Other languages are multi-paradigm: C++, O'Caml, Python,
just to name three, let you use several paradigms together,
in reasonably smooth ways.  The price of that is typically
_complexity_ -- but Python is an exception... it "reaches
out" to multiple paradigms *through simplicity*.  This,
IMHO, is part of what makes it such an outstanding language
for teaching: you can use it to help students learn to
wrap their minds around programming problems in different
ways, _without_ burdening them with complication, including
"strange" syntax.

People who "know" that the only one "right" way to program
is through a single given paradigm 'X', for any 'X', may
have little interest in Python (or C++ or O'Caml...).  If
X is 'lazy functional programming', then Haskell and Clean
have it covered; if it's 'statically typed object-oriented
programming', Eiffel or Sather; if it's 'dynamical object
oriented programming (single-inheritance)', Smalltalk; and
so on, and so forth (not to be confused with 'so Forth':-).

People who 'know' the very opposite -- that multiple paradigms
widen one's mind, and are typically needed for rich, complex
programming tasks in the 'real world' -- may still be rightly
reluctant to give multi-paradigm exposure to students at the
price of using a rich, composite, complicated language.  But
Python lets you have your paradigms and eat them too...!-)



> Here are two:
>
> Clean at: http://www.cs.kun.nl/~clean/
>
> Caml at:  http://pauillac.inria.fr/caml/
>
> Both of those languages are OOP too, and easier to use than Python.

I dispute both of your claims.  _O'Caml_ (the current dialect)
does have OO (as well as other paradigms: the 'basis' is non-lazy
FP, but OO and laziness can be quite smoothly 'tacked on'), but
'Caml' without the leading 'O' doesn't.  And Clean doesn't even
*claim* any OO-ness -- "The programming language Clean is a general
purpose, state-of-the-art, pure and lazy functional programming
language", states
http://www.cs.kun.nl/~clean/About_Clean/about_clean.html,
and continues "designed for making real-world applications" -- a
key issue: it's NOT designed for ease of learning, most particularly
NOT for ease of learning by somebody not yet steeped in higher
maths!  If a lazy, strongly-typed FP language were to be used as
somebody's first introduction to programming, I think Haskell or
HUGS might prove easier (but I have no real experience in attempting
such teaching tasks); Clean's claimed advantages over Haskell are
centered on performance issues, minor ones in teaching.  OTOH,
practical disadvantages include (last time I looked, at least)
no Linux support; the latest GUI library is currently Windows
only, with a hope to have a Macintosh port -- no Linux plans that
I know of.  This looks like a huge practical handicap to me!

Caml, IMHO, has rather cluttered syntax when compared to Haskell
(or Python!); it only gets worse when the Object-oriented extensions
are also considered.  Admittedly, a minor consideration, but, _for
the specific issue of programming-newbies_, not a negligible one
IMHO.  I consider the full O'Caml language too rich and complex
for an _introduction_ to programming, although, exactly because
it is so big, I guess it could be "subsetted" with some success
(just as those [IMHO] so misguided as to use C++ or Ada for a first
course in programming basically _have_ to subset it heavily to
have any chance -- O'Caml is NOT as huge/complex as C++ or Ada,
so the subsetting would not be as 'heavy' &c, fortunately!).

Again, the advantage of O'Caml vs, say, other more standard ML
variants, is basically one of _performance_ (in fact, Clean might
claim that its superior performance wrt Haskell comes in part
from a 'superior', better-cohesive, underlying conceptual model;
I don't think any O'Caml advocate would claim better conceptual
cohesion that standard ML...), stemming in part from richness.
These are not issues that would recommend the language for the
specific purpose of teaching a programming-introduction course.


In fact, if I _did_ have to base a first course in programming
on a purely-functional language, I think I'd choose Erlang -- not
without some misgivings (Erlang's concurrency model may not be
easy for programming beginners to grasp...!), but I strongly
suspect the dynamic typing model would ease my life as an
instructor, by enough to make the choice worthwhile.  (Scheme,
Lisp, or Dylan would also offer some dynamic typing, of course,
but then, they're not purely functional -- and there are other
issues with their use in didactic settings).

But my Numero Uno choice would still be Python, unless strong
external constraints precluded it.  And I hope I've shown this
is NOT because of a lack of open-mindedness, or interest in
other languages, but rather comes from a wide (if sometimes
not as deep as one would like!) examination of the field --
although I'll freely admit that teaching total beginners,
particularly ones of middle-to-high-school ages, has NOT been
an extensive part of my experience in the programming field,
and so I'll gladly listen to 'domain experts'... at least, if
their experiences extend to two or more languages and paradigms
in ways that make fruitful comparison and contrast feasible!


Alex