[Idle-dev] Py-CVS Release 2.1 Merge

[Bruce Sherwood]

Dave has said it very well. I can only add a vote and a testimonial based 
on my own experience and that of about a hundred college freshmen pounding 
on VPython with Dave's Idle this past year. These were students who had 
never used Python nor Visual (Dave's 3D module), and a sizable minority had 
never written a program before.

The behavior of this Idle, implemented by Dave Scherer with heavy design 
participation by the VPython group, is quite wonderful. Let me say 
immediately that as he says, there should certainly also be a shell for 
those who find it useful. In this regard I recently rectified a mistake and 
changed the VPython installation for Windows to leave the standard Idle in 
place, with its regular Start Menu icon, and simply added additional icons 
on the Start Menu and the desktop for invoking the editor.

It is possible that the shell has been popular because it provided 
significantly higher interactivity than the editor did. But as Dave hints, 
this is in large part because the original Idle editor made the 
edit/run/edit cycle quite cumbersome. As I remember it, the cycle went 
something like this: When you tried to run, you got a dialog box telling 
you to save the program. You had to click to get rid of the dialog box. 
Then you had to save the program. Then you could run. It was a lot of 
keypresses.

In the new editor environment, you press F5 and you're running! It's 
comparable to pressing ENTER in the shell. There is an automatic save just 
before the run, so even when we suffered some crashes in the classroom, 
students didn't lose work. (The crashes turned out to be cured by updating 
the video driver -- nothing to do with Python or Visual.) And you can leave 
the 3D window open while you change your code, then press F5, which kills 
the previous run windows and restarts. Etc. It is hard to list all the many 
little details that work exceedingly well, and well together. One other 
example: You can leave the scrolling print output window up, and each time 
you run there's a new header, so that it is easy to paw back through output 
to the top of a run.

The interactivity is very high, probably even higher than in the shell. 
When I was learning Python and learning Visual, I found the fast edit/run 
cycle much more supportive than trying to work in the shell. When I edit, 
it is easy to change an early line in the program, press F5, and see what 
happens. I found it very difficult to do that kind of exploration in the 
shell. I gather than experts can use the shell to very good effect, but I'm 
convinced from my own experience and that of our many students that an 
editor is much preferable, at least initially (not that I personally now 
see any reason to become expert in using the shell, though). I also found 
it quite opaque getting a mental model of what modules were loaded or not, 
whereas this is all completely transparent in the editor environment.

I understand that Guido is uncomfortable with automatic saves. But they 
work marvelously for the novice, and the expert once told can decide to 
save a copy somewhere at appropriate times. Also note that during a session 
there is unlimited undo. The automatic save NEVER caused our students 
problems, neither operational nor functional. Rather it made a major 
complication of programming something that just worked as expected and 
vanished into the woodwork. Our students could focus on the task rather 
than on the mechanics.

It would be interesting if someone who feels very productive in the shell 
could spend some time in the new editor and report what operations, if any, 
they find are poorly supported in the editor compared with the shell.

Bruce

> --On Saturday, July 14, 2001 16:51 -0400 David Scherer
> <dscherer@vysics.com> wrote:
>
> There should be two separate ways (e.g. two separate start menu icons on
> Windows) to start the editor and the shell.  I believe there is already
> a way to start in shell mode using different command line arguments.
>
> The VPython idle starts in editor mode by default because the shell mode
> does not provide remote execution (which is essential for us) and
> because Bruce and Ruth were not interested in the shell as a pedagogical
> tool*.
>
> Dave
>
> * Because of the irreversibility of actions: unlike in an editor, "undo"
> doesn't, and correcting a mistake can sometimes be impossible.  The
> "responsiveness" of a shell, on the other hand, is very nice for
> learning, so we tried to get as much of that as possible into the
> editing environment (e.g. with single-key run).  The preferred use of
> the editor is then to re-run the program after every few lines of code!