Python in "math through programming" curriculum

[Neelakantan Krishnaswami]

On Wed, 20 Dec 2000 13:52:53 +0100, Alex Martelli <aleaxit at yahoo.com> wrote:
>"Neelakantan Krishnaswami" <neelk at alum.mit.edu> wrote in message
>news:slrn9402bt.fa6.neelk at alum.mit.edu...
>    [snip]
>> I disagree with you here about Python's appropriateness. Conceptually,
>> the strongly typed FPLs are the best languages there are for learning
>> about the mathematics of computer programming. The combination of
>
> I wouldn't consider anything but Haskell if I were to teach "the
> mathematics of computer programming" (that may be because my
> exposure to Clean is too limited) stricto sensu [...].
>
> But "math through programming" is a completely different issue,
> at least as the original poster meant it (as he explained in a
> followup to this post of yours) and as I took it -- middle and
> high school levels, as he had said!  

Yes -- the reference to Knuth's _Concrete Mathematics_ made me think
that an introduction to CS was envisioned. For things like graphing
and statistics, there's no reason not to use Python, since it has good
graphing and statistical libraries. Static typechecking doesn't help
here, I don't think, and in Haskell's case it becomes a positive
nuisance (because of all the IO).

> I would *NOT* introduce Haskell in middle school, and even for high
> school, I have my doubts -- students would have to have strong
> *previous* exposure to mathematical concepts, AND to computer
> programming; few high schools, I suspect, are good enough for that.

I do think a typed FPL would work at the high school level, once the
kids have gotten exposed to algebra (for the idea of functions) and
geometry (for the idea of proofs). Then Haskell could be used as a way
of teaching them how to write proofs. It has the two great advantage
that proofs are programs, and hence executable and testable, and that
it has type-checking to help catch errors in them. Call it
experimental constructive mathematics. :)

You would definitely want to improve the quality of the error messages
these implementation emit though. An adult programmer would find them
feasible to work through, but something like

ERROR: Type error in application
*** Expression     : foldr (*) 1 take n (enumFrom 1)
*** Term           : take
*** Type           : Int -> [b] -> [b]
*** Does not match : [a]

will not help a ninth-grader figure out she needs to add some parens
and write "foldr (*) 1 (take n (enumFrom 1))" to compute the factorial.
And this is a very good error message, compared with most!

>> > 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.
>>
>> This is the *big* weakness of the ML-family languages (including
>> Haskell and Clean): they all have gnarly syntaxes. Python is proof
>
> Haskell's syntax is *lovely*!  How can you class it in "the ML
> family"?  [Again, I don't know enough Clean to have a real opinion
> about it].
>
>What specific objections do you have to Haskell syntax...?

Honestly, Haskell looks very similar to ML and OCaml to my eyes. An ML
program translated to Haskell will read very similarly[*].

Some of the peculiarities of Haskell's syntax that I find annoying are
the use of case to distinguish the type and value namespaces, the use
of '\' to introduce lambdas (I find this ugly and twee), and the $
syntax to force strict evaluation. However, these are all fundamentally
nuisances, rather than mortal wounds.

However, a really huge lose is the do-notation, which is fantastically
ugly. I *love* the way that monads let me type effects in the language,
but I hate the way I have to type effects in the editor. :) IO is 
important enough that it shouldn't be painful to use.

[*] The usual caveats about tail recursion and lazy languages apply;
I'm assuming them away for the purposes of example. 


Neel