[Edu-sig] The fate of raw_input() in Python 3000
john.zelle at wartburg.edu
Wed Sep 13 15:52:42 CEST 2006
A new twist on this thread: discussing the very nature of intro courses.
Should we read more code and program less, should our programs build to
something and not be a bunch of random scripts?
I think it's obvious to everyone that a course that tackles "real world"
problems will be more interesting than one that doesn't. But that doesn't
mean simple scripts can't address real world issues. While it's true that the
first programs are not polished applications, they certainly can solve real
problems. It's also obvious that by the end of the course, students should
have progressed beyond the "simple script" phase and be able to write
programs that are truly intresting in their own right. A good class is one
that can have multiple projects building toward some larger result. Of
course, the downside here is that a project that really interests one student
may be drop-dead boring to another. Notice that each of you is talking about
how you learned by tackling a particular project that was of interest to you
personally. It's hard to manage a class of, say, 10 different cumulative
projects, although I frequently allow students to choose among several that I
lay out for them. BTW, this focus on solving "real" problems is what keeps me
from using an approach like Alice.
As for spending more time reading programs and less time writing them, if
anyone thinks this will interest and motivate _more_ students, I suspect that
person has never actually tried to teach a class. It is success in writing
programs that keeps students interested and motivated. There's nothing better
than that "Yahoo!" when the program works. It's a battle to get students to
read any code at all. I specifically chose not to "box off" code in my book
to get students used to actually reading the code as part of the text, not
as "extra material." Typically students will just "skim over" larger program
Finally, all of us can learn a lot by reading others' code, but there is no
substitute for actual programming to learn the full problem solving mindset
and skills. Once again, most intro CS courses are not just about learning a
language. That's a means to a deeper end, which is learning algorithmic
thinking and problem solving. Imagine an introductory German class where the
students were not asked to actually speak or write German. They might still
be learning a lot, but it would not be nearly as useful. So yes, we want our
students to be reading cade, especially good code, but I also want my
students to be writing programs, lots and lots of programs. It's hard to
appreciate what makes code good until you've written some bad stuff yourself.
On Wednesday 13 September 2006 7:18 am, Arthur wrote:
> Peter Bowyer wrote:
> > At 11:47 13/09/2006, Arthur wrote:
> >> I can imagine an introductory course that was in fact more a
> >> *reading* course than a writing course - that spent a good deal of
> >> its time analyzing the code of relatively straightforward, but
> >> interesting, working applications. The satellite view, before we
> >> attempt to descend to a finer resolution.
> > That's a lot like how I learned to program. I bought a book
> > (Professional PHP - nothing like an intro book!) and once I'd read
> > some basics I went in and wrote a proper application - an ecard
> > script, following the outline of Perl code that I'd read previously
> > (without being able to write). That way I learned from someone else
> > (apprenticeship) and wrote something that was *useful* when finished
> > (encouraging me to learn).
> Myself as well. My first "major" Python project was simply a port of
> some Java code to Python - a 3d math library. Read/write - read the
> Java, write the Python. But in the end I had something actually useful,
> to an extent I could not possibly have accomplished at that point on a
> write/write basis.
> All this of course makes Open Source of central importance. It happens
> that the 3d Java library I wanted to port was not open - nice API docs,
> no source. Luckily someone in Japan had taken upon themselves to do a
> functionally equivalent Open Source version of the library, .i.e.
> creating functional source working backward from the API.
> As it happens, on a *read* basis, about the first thing one can expect
> to encounter and need to explain (maybe after the doc string) is the
> "import" statement. To me this feels exactly right. OTOH, a recent
> post on the Python3000 list - discussing the fate of raw_input() -
> re-iterates the position that an understanding of the import statement
> is something that belongs way, way down the road - in a way that was
> much to sure of itself, for my taste.
> That one point - where the "import" statement belongs, pedagogically -
> seems to in some way represent the quake line of different points of
> view. Bucky might recognize this fact as a symptom of a pre-synergistic
> stage of things. But one side or the other always needs to lose some
> surety in order to make a first move in the direction of synergy..
> You first ... whoever you is ;)
> > When studying physics I found the same approach worked, taking a
> > real-world application generated enthusiasm for learning esoteric
> > subjects. If you enjoy learning for the sake of knowledge I guess
> > this approach isn't needed; otherwise I believe it to be the most
> > effective approach.
> > Peter
> Edu-sig mailing list
> Edu-sig at python.org
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