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

[John Zelle]

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 
examples.

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.

--John

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 ;)
>
> Art
>
> > 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
> http://mail.python.org/mailman/listinfo/edu-sig

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