
On Fri, 2005-06-03 at 01:59 -0700, Toby Donaldson wrote:
When I taught VB (Visual BASIC), however, the GUIs were great, and students almost universally said the course was more interesting and enjoyable because of them. In part, they liked the fact that their programs looked like real programs, and that there was some room for creativity in how they organized their interfaces. Student were often driven to do extra programming by a desire to add or fix features they had seen in programs. I liked the fact that there was a very clear design phase where you had to sketch out the interface. Talking about the interfaces was a good way to talk about the program without talking about the source code. This helped students organize their source code, and to see first-hand the benefits of modularity, i.e. they were always writing the code for widgets in specially-named functions. Also, GUI widgets roughly correspond to programming concepts, when deciding if you want to use a text book or a list (say), you are indirectly deciding which data s! tructure you want to use. Some students said they thought that learning VB first made it easier to understand Java-like OO GUI models.
Toby, check out pythoncard (http://pythoncard.sourceforge.net/). I have a student this year, Daniel Caughran, who used it for his science fair project, and he compares the experience favorably to using VB (with which he is familiar). He was able to put together a very useful GUI program with a minimum of effort. Version 1.0 will be out soon. It looks like teachers using Python can now offer their students the advantages of VB without the disadvantages.
As much as I like Python and dislike the BASIC part of VB, I do have to admit that my experiences with VB were probably the best I ever had teaching introductory programming (although it wasn't quite a CS1 course, just a humble introduction to "event-driven" programming).
I "taught" VB for a year, and was amazed to find out that I made it through the entire year without either myself or my students (naturally) learning much of anything about programming. To be fair, that is not the fault of the tool itself (though the tool did contribute to the problem), but rather the fault of the approach used to teaching it (it was my fault, in other words, but let me explain ;-). We used a Shelly Cashman book as the textbook for the course (I had nothing to do with choosing it). These books seem to be popular with some folks inside the school system because they keep students busy (and thus, the reasoning goes, out of trouble). They also teach students almost nothing. Long, complex procedures are illustrated step-by-step, with screen shots showing exactly what the screen should look like at each stage. Students are able to follow the instructions step-by-step to achieve the desired result (thus they are kept busy), but the focus is almost exclusively on the environment and the procedures are way to complex for students to be able to extrapolate much of use from the experience. It is my hope that the grass roots nature of the Python community will prevent this same kind of thing from happening with our teaching materials, particularly as more and more people are using Python. The eclectic, cross platform, multi-environment nature of Python programming will make it difficult for a Shelly Cashman type book to be written. Or at least we can hope... -- Jeffrey Elkner <jeff@elkner.net> Open Book Project <http://ibiblio.org/obp>