[Edu-sig] Future of CP4E after CNRI?

[Kirby Urner]

>Obviously, you also appreciate some more details where they
>are available and would also be happy if such nasty little
>questions as mine would help people to stand firmly behind 
>their announced openness. Glad to hear that! ;-)
>
>Regards,
>
>Dinu

I have no problem with your questions, which I thought 
were constructive.  I would only consider it whining if
it got to the point where people are finger-pointing 
and saying "who killed CP4E", as we clearly have all 
the tools in hand to move CP4E forward in one shape 
or another.  If not in the shape originally envisioned,
oh well, such is life.

Re case sensitivity, I personally have no interest in
a non case-sensitive version for learners, would consider
that a patronizing and condescending approach, as if the
complexity we teach in ordinary language somehow goes
out the door when it comes to computers (all kids learn
upper/lower case just to be competent in their native
language -- non-alphabetic languages excepted of course).

What I'd like to see is better integration of math 
teaching with computer science, ala 'Concrete Math' by
Knuth et al, but at a more 'Sesame Street' level.  This
would mean aquainting kids with ASCII early, in 
combination with base 2 arithmetic and permutations/
combinations of 1s and 0s more generally.  Once you 
feel in your bones that 'A' and 'a' are paired with
two entirely different bytes (or unicode wydes), then
it's less of a problem to allow case sensitivity in
your code (note:  I use Xbase a lot, which is NOT case 
sensitive -- I'm not saying all languages _should_ be 
one way or the other, just that once you've made a 
design decision at this primitive level, it's sort of 
wasteful to backtrack and try to please everyone).  If 
people ask for a non-case-sensitive Python, I think 
they should be told "no, sorry, not in the cards".  
Again, that's just my personal view.

Likewise with IDLE -- it's a great little tool, and
pretty stable.  Color-coding of key words is very standard 
in high end editing environments for all languages, as 
is some kind of run-time debugger (which is useful for
teaching, showing how variables are changing as the 
interpreter steps through code).  It's not a "dumbing 
down for kids" or a "toy" feature in any way.  I'd like 
IDLE to stay lean and not start doing feature bloat with 
the idea of compensating for naive users with no prior 
experience.  I prefer Linux aesthetics to the hand-
holding Microsoft approach (even though I am in Windows
more of the time these days), with talking paper-clips 
and the like.  We don't want Python to turn into some 
kind of bloated "Bob".

In sum, I personally don't think "computer programming
for everybody" means stuffing an already working environment 
with a lot of "dumbing down" bells and whistles so that 
people just don't have to retrain their reflexes in favor 
of case sensitivity or whatever.  There _will_ be a learning 
curve.

In my reality, Python is an asset, a tool, pure and simple.
I don't need it to improve or "get better" for my own
purposes.  What I'm focussing on, when it comes to change
and improvement, is not Python, but the whole overly
compartmented and fragmented approach to 'numeracy', 
which insufficiently integrates threads, is a hodge-podge
of holdovers from previous eras.  I'd rather debate why
we're still using TIs and graphing calculators instead 
of full-fledged computers, and why math teachers-in-training
are given so little programming as part of the mix (because
that's "computer science" -- some other discipline entirely
we're supposed to think (but I'm not buying)).

In sum, there's nothing wrong with Python, and the roadblocks
to CP4E has little if anything to do with deficiencies in
the Python language, and everything to do with an obsolete
curriculum that deserves to be overhauled in a hurry, 
before another generation is sacrificed to the gods of 
tunnel vision.

Kirby