[Edu-sig] IDLE/TK limitations for learning environments
Fri, 04 Feb 2000 18:32:54 -0500
David Scherer wrote:
> This [using exisiting IDEs] may be appropriate in the very short run.
> However, I think that a
> completely cross-platform IDE suitable for novices needs to be developed,
> packaged with everything that will be needed for novice users in an
> absolutely airtight installer for every platform, and distributed with
> tutorials and course materials.
However, I do also see Steve Litt's point about the weakness of IDEs in:
"Keep Python's advantages". He is quite correct in pointing out that
IDEs may add another layer of complexity to the learning task. Of
course, this assumes the user knows how to use an editor (and their OS)
and this is not also somehow part of the instruction.
Ah, the good old days of starting up a Commodore PET or C64 and just
typing in BASIC... And I don't mean that sarcastically. Those were good
days for learning programming -- instant on, no GUI clutter, immediate
responsiveness, easy interruptability, even if it meant the power
We should strive to provide that sort of immediacy and recoverability in
learning environments. To the extent that GUIs get in the way, or
provide one more thing that breaks, they can be one more hurdle as Steve
We need to use the power of the machine and GUI to make things easier.
How to do that is a difficult question -- especially when assuming total
novices, and maybe no teacher, and you are considering the entire
experience. Really, you want a user to get a friend to help download an
EXE (or whatever), and then run it and be hand held by the program
immediately to the degree the user needs it from there (even avoiding
install choices if possible!).
Web page tutorials also might help, assuming the user knows how to
access them at the same time. Otherwise at least the core needs to be
> Another issue is that the IDE needs to be absolutely stable. IDLE and most
> other Python IDEs share a single Python interpreter with the user program.
> I am convinced that this architecture is unacceptable for novice users (and
> for me!)
You hit the nail right on the head!
Beginners have the least tolerance for delays and failures.
Now that I think about it, this single interpreter is probably what is
bothering me most about debugging with IDLE. I end up using IDLE to
write code because of the prettyprinting and launch the Python programs
seperately from a shell command line to get error messages. Or if I am
desperate, I think I get one launch under TK from IDLE to get error
messages before launching under the debugger won't work.
A learning environment needs to be much more forgiving and reliable than
average. Compartmentalization and "remote debugging" seems like the way
A learning environment also needs to hide much complexity (which entails
some big changes). For example, for LearningWorks they modified the
debugger to hide messages not related to the learning task. So, in
Smalltalk's case, intermediate send and dispatch methods and lowest
level errors (a final exception) were hidden from the beginning user.
In the case of IDLE for example, to use the debugger in single step mode
you may have to step through a lot of initialization code you don't want
to. I still don't clearly understand when I can and cannot set various
break points. A debugger that lets a learner focus on one section of
code, and limited layers of code, is invaluable to the novice. While an
expert knows when to step in or jump over, a novice does not. This is
the sort of thing a learning environment should provide -- so for
example if a novice is developing a GUI application as part of a
learning exercise they can step into their code but not a library.
Obviously they may need to understand the library eventually, so how and
when they step into the library code is an issue of some complexity.
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator