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@python.org > http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA [EMAIL PROTECTED] (319) 352-8360 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
