[Visualpython-devel] Re: [Idle-dev] Py-CVS Release 2.1 Merge

[Kurt B. Kaiser]

Bruce Sherwood <bas@andrew.cmu.edu> writes:
> Both Ruth Chabay and I individually tried
> hard to learn Python in the shell environment and both of us just got very
> confused. We didn't want to see what one statement did, we wanted to put
> several statements together. Given our very bad experiences, I'm curious what
> evidence you have for the shell being a good tool for learning Python? 
> And what
> are you comparing to? Dave Scherer's highly interactive editor, or a batch
> oriented environment with no interactivity?

In my experience, and as Stephen says, its useful to be able to do experiments
in the shell.  If anything comes out of this, I copy and paste into an editor
window.

_However_, when you get to the point where you are importing modules, and
changing those modules, then IDLE gives distinctly non-intuitive results.

I developed a technique, which quickly became second nature, of reloading, and,
if I had used from XX import *, redoing that. This is easy, just up arrow a
couple of times and hit return twice. BUT it is not obvious.  If you don't do
that, you get "bad experiences" which are difficult to explain/justify to
beginners.

It would not be necessary to save the state of the editor file if it never
died! But in practice, up to now, it is not 100%, because you can kill Python.
Most IDEs give the option, and I always turn it on. If I want backups, as Bruce
says, you learn to take snapshots at appropriate points. It's just a different
way of working.  I'd say, automatic saves.

With beginners, things should be as intuitive as possible. Dr Scheme has run
into this headlong and they have set up their environment, which is also an
editor window and an interactive window, to handle the problem. They reset the
interactive window each time you run something from the editor window. They
have documented their design:

http://www.cs.rice.edu/CS/PLT/Publications/jfp01-fcffksf.ps

Refer to section 3.2. Quoting:

"Experienced functional programmers have learned to avoid this problem by using
their repl in a fashion that mimics batch behavior for definitions and
interactive behavior for expressions. They exit the repl, restart the
evaluator, and re-load a program file after each change. This action clears the
state of the repl, which eliminates bugs introduced by ghosts of old
programs. Unfortunately, manually restarting the environment is both
time-consuming and error-prone.

DrScheme provides and enforces this batch-oriented style of interactive program
evaluation in a natural way. When the programmer is ready to test a program, a
click on the Execute button submits the program to the interactions
window. When the programmer clicks on Execute, the repl is set to its initial
state and the text from the definitions window is evaluated in the fresh
environment. Thus, the repl namespace exactly reflects the program in the
definitions window. Next, the programmer evaluates test expressions in the
repl. After discovering an error, the programmer edits the definitions and
clicks the Execute button. If the programmer forgets to execute the program and
tries to evaluate an expression in the repl, DrScheme informs the programmer
that the text of the program is no longer consistent with the state of the
repl. In short, after every change to the program, the programmer starts the
program afresh, which eliminates the problems caused by traditional repls. For
large programs, restarting the entire program to test a single change can be
time consuming. Although restarting the repl in this manner can be
time-consuming for large programs, the first author still uses this style repl
to develop DrScheme itself, albeit with selected, unchanged libraries
pre-compiled to an intermediate byte-code representation."

Expert people, expert techniques. Beginners need something like the Dr Scheme
environment. 

Regards, KBK

"Beginner Mind"