On 9/8/06, kirby urner <[EMAIL PROTECTED]> wrote: > (2) prompting oneself for input is a holdover from prehistoric dino > terminal window days and should not be front and center. Just like > with 'copy' we put it up on a shelf, to discourage accessing this > 'honey jar' of a previous generation (bad habits are hard to break)
I was thinking about that this morning. I used to teach programming each summer at a math camp, and as a math teacher I have an opportunity to directly teach a programming course every few years (we have two math teachers with CS degrees who each do .5 to .8 programming, but every so often there is an overflow section which would tend to go to me). The curriculum that I inherited and modified in order to teach programming through Python, I initially translated from a nominally C++ curriculum that looked a lot more like a C curriculum. I edited it to include more object-oriented frame of thought, and injected some Tkinter (which did wonders for student interest). The C++ / C curriculum that I modified was probably a revision of a Pascal curriculum, and I don't know the origin of that Pascal curriculum. The model that I tried to convey to the students was that First, a computer program has OUTPUT. We would use print for an 80-minute day and Tkinter for something like a week to simply produce output (which is less boring if you include things like for loops in this time). Second, a computer program has INPUT followed by OUTPUT. This was where raw_input was nice, and students were to use raw_input followed by typecasting for numerical values. Third, a computer program has INPUT followed by COMPUTATION followed by OUTPUT. Eventually they learned to embed a try: except: in a while not loop in order to force the user to give an expected numerical value as the response to a raw_input request. This summary does an incredibly poor job of conveying the pieces of object-oriented thought that were included (e.g., string and list methods early on), but what I see happening with dropping raw_input is that we will probably want to completely and totally revise the curricula such as the one that I just described. I see a little more give-the-kids-a-black-box-module-and-have-them-call-it, which is very popular in java programming. And, of course, I'll want to completely re-write my own syllabus on the next round. Lots more Tkinter, most likely. This (need for curricular revision / rewriting from the ground up) is not a wretched thing, but it is a time-consuming one; and almost every utility program that I have written only for myself to use is now going to be broken. I remember a bit of pedagogical pain when in earlier versions of Python, all of the tutorials said to call a Tk mainloop(); then in IDLE the programs would kill IDLE itself when exited. So I told my students to write the mainloop() invocation, but to comment it out. Eventually I forgot about it. Then when I took the same lesson to a later version of Python, IDLE became smarter and the mainloop() invocation became (properly) necessary again. Every time that old code becomes invalid, there is a risk that not only programs won't run, but (especially if the instructor trusts fundamentals not to shift) lessons are broken as well. Again, I'm not saying that this is a bad thing, but it can be a painful one (especially if a new version of the language is embraced without checking through all of the sample code in each already-written lesson). There is also a risk that folks will freeze at an older version in order to avoid breaking old code. I'm sure that the obvious has also been stated elsewhere. -Lloyd, a TEACHER. (I'd tend to want to change the subject: too, but that would make it hard for me/gmail to track the thread) _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
