[Edu-sig] The fate of raw_input() in Python 3000
john.zelle at wartburg.edu
Sat Sep 9 17:18:40 CEST 2006
On Friday 08 September 2006 4:27 pm, kirby urner wrote:
> On 9/8/06, kirby urner <kirby.urner at gmail.com> wrote:
> > You're not making a monkey out of your mom, by making her loop through
> > some little menu, oblivious of the language underneath, its logic and
> > design. You're "protecting you mother" (aka paradigm end user) from
> > knowing *anything* about Python. That's your goal, that's the whole
> > point (i.e. end user = not a programmer).
> Just to clarify: I think it *is* condescending to newbies to force
> them through a lot of raw_input scripts, since this is:
> (a) not state of the art from and end user's point of view nor is it (not
This is like saying that Physics students have to start with General
Relativity and Quantum Mechanics, because those are state of the art. No one
is denying that it's good to teach GUI programming at some point. Is that the
simplest way to introduce programming? My learning philosophy is to always
search out the simplest thing that illustrates the principles I want my
students to learn at the moment. Anything more complex is just adding noise
and complicating the learning process.
> (b) not state of the art "coding for self" idiom (which'd be more
> shell interactive)
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
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:
Import a module
Recall what I'm suppose to invoke and what information it needs.
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.
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.
> 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
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.
> 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.
> We'll know about 'strings' just as surely as we know about 'numbers'.
> Why? Because "computer literacy" is not just for some tiny inner
> circle. It's just basic fluency. Like my friend Gene Fowler puts it
> (paraphrasing): any poet worth his or her salt should know about XML
> already. http://controlroom.blogspot.com/2006/08/more-cast.html
None of the poets I know care a twiddle about XML. I guess we just move in
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360
More information about the Edu-sig