[Edu-sig] The fate of raw_input() in Python 3000

[John Zelle]

On Saturday 09 September 2006 12:35 pm, you wrote:
<snip>

> But mostly I'm advocating going to the other extreme:  drop GUI as a
> topic and just code up a namespace, reach into the grab bag for
> functions, like f(x) or cos(x).  We pretend kids don't have the
> background, but if they did *any* work with a TI calculator or an
> algebra course, they know about functions, at least tacitly.
>
> My prerequisite for my Saturday Academy class is algebra only, and
> typing above 30 a minute really helps (a lot of 'em are getting that
> from chat rooms these days, buy a typing drill for home).
>

As I said below, I'm all for this kind of interaction, and when input and 
raw_input go away, I'll probably do more of it.

> > While I accept the power of twiddling in the shell particularly as an
> > educational tool (again, I come from a Lisp/Prolog tradition), this
> > statement is just silly. How can you define "state of the art" for any
> > "self" but your own. When I write a script to automate some routine task,
> > I virtually always
>
> I can define it for my gnu math teachers, the people I work with in
> South Africa for example.

This, of course, misses my whole point that you can't define "state of the 
art" in "programming for self" for others (me, for example).

> > use interactive text input. Why? Because the whole point is to make
> > something routine and automatic. Why would I write a program that forces
> > me to: Start Python
> > Import a module
> > Recall what I'm suppose to invoke and what information it needs.
>
> Sounds like your "program" is one of these top-to-bottom
> glued-together script thingys.  We don't teach that way.  Modules are
> grab bags, perhaps containing rich data structures (lat/long
> dictionary say).  Modules define namespaces, like boxes of chocolates
> (Forest Gump understands).

First up, I was not talking about the way I teach, but the way I program to 
automate my environment. To use your terms: defining state of the art in 
programming for myself. Your model is less convenient for these tasks than 
the one I describe.

Further, I highly doubt that the script I'm writing for those purposes are any 
less modular than they should be to get the job done. Namespaces are a 
wonderful tool (which I use liberally), but don't confuse being modular with 
being good. There's plenty of bad modularity too. 

> This need to glue it all together with some main() -- why?  We compete
> with that idea of "programming."  We're not a part of *that*
> particular conspiracy.

Umm, the point of  my program is to automate something. That's why I glue it 
together.  If I don't do that, I haven't solved the problem I set out to 
solve. I'm only 'conspiring' to solve the problems I have at hand.

> Last week, we were working on phi and the fibonaccis.  Let's get back
> to that now.  Pull out a file drawer (import) and behold: all our
> favorite specimens (even the bugs are back).

Great. Fantastic. It has nothing to do with what I was describing. I have 
plenty of these experimental evnrionments as well.

>
> > Instead I can write an incredibly simply script that I just click on, and
> > when it needs information it prompts me for it. That's _my_ state of the
> > art in programming for myself. And it's something I can teach students to
> > do for themselves in very short order.
>
> Yeah, we don't like that style.  OK for you, works for your students,
> I think you're probably a dynamite teacher.  But...  we still don't
> like that style.

Again, I'm talking about writing a useful tool to automate some mundane task. 
What's "not to like about that style"? Should I make automating that task 
harder so as to fit your pedagogical style?  My arguments had nothing to do 
with how you or I go about teaching math. 

> Later on maybe, if/when they're committed to CS.  But this is just
> basic numeracy here, and they already know about functions from
> calculators.
>
> import math
> math.cos( 90 * math.degrees)
>
> -- that's what a first class might include.  If what stops 'em isn't
> the Python syntax, but the trig, then we go over the trig.  Basic
> numeracy.  All as a bundle.  Not your grandfathers math class (but
> some hoped it'd be for their kids -- remember when the future was,
> well, futuristic?).

Again, this sounds great. I like it, and I'm glad you're doing it. And you 
don't need raw_input (or input). But having input available in no way impedes 
this, and for the tasks I'm describing, lack of the same is a hindrance.

> > Whether I'm writing for myself or whether I want my students to be able
> > to write the simplest possible useful programs for themselves and others,
> > that involves textual input. I'll say it one more time: IO is fundamental
> > to programming; the simplest universal form of IO deserves to be in the
> > core language so that it is easily accessible and available everywhere
> > the language runs. Pascal got that right and Python (pre 3000) has it
> > right.
>
> And I'm saying using the shell to trigger namespace events is (a)
> closer to what a GUI is doing and (b) is fully usable I/O.  Use doc
> strings to remind about inputs.  raw_input prompts are the new goto
> (to be avoided if possible).

But it's less convenient and therefore less useful for producing real tools 
that automate tasks. You are talking about a different form of programming 
and pedagogy. Docstrings do not solve the problem I describe, because they 
are passive. I have to go look at them again to remind myself how to use the 
tool. If I write a program, the program itself knows what it needs and when. 

> > > As teachers, we shouldn't be propagating the hidden assumptions that
> > > go with raw_input, i.e. that there's this class if people out there
> > > "too dumb" to know anything about namespaces or functions.
> >
> > Translate this to any other discipline. Running with my physics example:
> > "As teachers, we shouldn't be propogating the hidden assumptions that go
> > with Newtonian mechanics, i.e. that there's this class of people out
> > there 'too dumb' to know anything about quantum physics or general
> > relativity."  Does

> Right, but I see that as a self-serving analogy.  You're *defending*
> the status quo.  Notice how CP4E goes for like "riding a bicycle" and
> "driving a car".  Anyone can do it, no big deal.

Well far be it for me to suggest an anology that supports what I'm 
defending :-). Is it true that anyone can write a working GUI program? I 
don't know if that's any more true than that anyone can comprehend quantum 
mechanics.

But let's use your example: does the fact that we expect everyone to be able 
to drive a car mean that we _shouldn't_ teach them to ride a bicycle? And 
shouldn't we even go a step further and take bicycles away because they might 
learn this useful mode of transportation which is _not_ car driving? Because 
it sounds to me like this is exactly the argument you are making w.r.t. 
input.

> I think CS has a reflex to fight "debasement" of programming into a
> "what your grandmother knows" skill.  But that's what I *want* to have
> happen, and expect grandmothers *will* have those skills in the not
> too distant future.
>

I hope what you want comes to pass. I can assure you that CS academics have 
nothing whatsoever against programming as a universal skill, since we profess 
to believe that CS is much more than programming and say so at every 
opportunity. I, for one,  can't wait to add a bunch more upper-level courses 
to the major when programming is taken for granted. I'm just not holding my 
breath...

> Latin moms in Rio will tell The Monkey to block those Evil Toons
> (point and click yes, but they custom-skinned the GUI, know how it
> works from hours study. What, working class folk with the free time to
> study what they used have to pay for, plus hold down a job?  What a
> concept!

OK, now I just have no idea what you're talking about. Probably that's because 
I'm stuck in my dino-world.

>
> > that really make sense? The fact that there is more advanced stuff that
> > they will surely learn in due course is in no way a justification for not
> > teaching simpler, useful concepts first.
>
> Nothing much simpler than import math, using the names.  Raw_input is
> difficult by contrast.

For Gnu-math maybe, but not for the types of useful artifacts I suggested 
above. And Input is no more difficult than typing expressions (as I've 
explained) which I assume is the starting point for your Gnu-math.

> Why don't calculators have raw_input?  They can't do I/O?  How about
> dashboards?  Cockpit of an airplane.

You are confusing what's easy for the user with what's easy for the 
programmer. Underneath, of couse, a modern calculator _does_ have the 
equivalent of raw_input. It grabs the string constructed in the display, 
parses and evaluates it. The user interface is all extra baggage built on top 
of that. From the programmer's standpoint, that extra baggage is more effort. 
If I already have a console, I can get the useful tool without the extra 
effort.

> We use control surfaces all day long.  That's what a namespace is, an
> API.  You don't need to tie it all together with some main().  This
> isn't a script.  It's a place to do work.  Namespaces are like
> studios.  Event driven.  More GUI, less "programming" (in the 1960s
> sense).
>

Right on. But what I'm talking about _is_ a script.

> > > I'm saying this'll all be common knowledge soon.
> >
> > Define "soon." I see the same demographic as Brad Miller. My students are
> > freshman in college who have never programmed. And frankly, I'm OK with
> > that.
>
> And frankly, I'm not.  High school too wasteful.  If it's really about
> sports, which is OK with me, lets do more sports camps.  But for kids
> who want academic rigor (another kind of sport), it's just not OK to
> not even *offer* OO by the end of high school.

What if they're not interested in it? I know in your world the schools are 
hopelessly outdated because they don't teach Gnu math and OO. I'm happy if 
they teach our children to read and write well and to do some mathematics. I 
don't even care much what math they do, just as I don't care much what they 
read and write about. Throw in a basic understanding of science, and a 
healthy dose of getting along with others, and you've got a curriculum. Of 
course, one can argue schools are not doing this now, but I don't see how 
teaching them to program frees up more time for what I consider fundamental 
skills. If your Gnu-math is better at teaching them some mathematics, that's 
great; I'm all for it. But I don't care if it teaches them OO.

One of the reasons for the conservatism of the educational establishment is 
that it can be devilishly hard to determine what the core skills are that all 
educated people should have (unlike other countries, our K-12 system attempts 
to be universal). You specifically mention OO and Python, but education 
(currently in the US) is a 13 year program. Will OO still be the dominant 
paradigm in a dozen years? I have a hunch not. OO institutionalizes 
side-effects (state change), and side-effects are a bane to managing 
concurrency. With multi-core, multi-processing machines seeming the most 
obvious routes to increased computing power, it could be that OO looks as 
old-fashioned as gotos in a dozen years. Is OO some fundamental/essential 
skill? I don't think you can measure the value of an education in terms of 
what specific technologies are learned (and OO is just a technology).

Fundamental education is not about what technologies we teach or what 
technologies we teach with; it's about what kind of citizens we raise. Give 
my children a good teacher that can really communicate and get the kids 
excited about _learning_, and what in particular they learn doesn't matter so 
much. They have their whole lives ahead of them to become great at whatever 
is meaningful to them.

> If USA voters want to keep that status quo, fine, but don't think the
> rest of the world will think twice about thrashing us in the job
> market if so.  Or were we planning to use the Pentagon to keep the
> rest of the world stone aged, while we went on being mental couch
> potatoes.  If so, think again.

> Praise the Lord we have television.  If the schools have decided to
> rust in irrelevance, letting it be OK that globalization passes us by,
> then we can do what we did in Sesame Street, except at a much higher
> level (still using puppets though -- some of them CGI).

This is an interesting juxtaposition of paragraphs. Many studies suggest that 
TV is the number one contributor to mental couch potatoism. I'd much rather 
have my kids spending time in our current (backwards, dino-era) schools (at 
least the ones we have here in Iowa) than watching television, no matter what 
show is on. Real interactions with live caring people in a social setting is 
what children need most. No truckloads of DVDs, screencasts, or electronic 
curriculum of the foreseeable future will change that truth. Until we have 
truly intelligent machines, there is no substitute authentic interpersonal 
interaction in terms of communication bandwidth. Education is at its core 
just communication.

> Our Snake with __rib__ syntax makes fun cartoons on TV.  It slithers
> around like Kaa, eating stuff (eat method).  Hah hah, the 3rd graders
> laugh.  Gnu math is just better.
>

I have no idea what that paragraph is about. Anyway, this is really, really my 
last post on this thread.

--John

ps. And I mean it.

-- 
John M. Zelle, Ph.D.             Wartburg College
Professor of Computer Science    Waverly, IA     
john.zelle at wartburg.edu          (319) 352-8360