[Edu-sig] Creating worlds -- graphical interfaces

Jim Harrison jhrsn@pop.pitt.edu
Sun, 06 Feb 2000 12:12:39 -0500

on 2/5/00 10:34 PM, Kirby Urner at pdx4d@teleport.com wrote:

> I'm not sure I agree with Jim that tight integration with
> a cross-platform GUI is essential.  Python is very good as
> a "glue language" that finds ways to establish working,
> collaborative relationships with a lot of other tools (Tk
> is one such).

I may not have been clear in my original post. I am arguing that a
well-integrated *GUI framework* for Python that allows students to create
GUI elements in their own programs is both pedagogically desirable and
essential for Python's success as a general-purpose teaching language in the
long term. I'm basing this partly on my own experience with my son, who
started programming when he was 9 and has gotten a lot of enjoyment from it
in the subesequent 4 years. He's worked with several development
environments, and the ones that are the most reinforcing are the ones that
provide a straightforward way to set up a GUI for his programs (and thus
generate "real" programs, in his view). I also suspect that many secondary
school teachers and administrators would take this view as well, and that a
low-cost "Visual Basic for Education" would be a strong competitor (though
much less desirable than Python from our perspective).

Randy Pausch's Alice Project provides a visual framework for program output
that immediately displays the results of program logic (in the setting of a
3D world) and is strongly reinforcing for students. His work tends to
validate the concept that visual output is a useful endpoint for programming
exercises. My preference, though, would be a more general-purpose framework
like Tkinter or wxWindows that allowed construction of a variety of
different programs, rather than just 3D worlds. This framework would ideally
be integrated with a Python educational IDE so that students could create
and manage interface elements in a straightforward way, without dealing with
the GUI framework as a separate entity.

In my original post, I was concerned that we were almost but not quite there
yet with Python GUI frameworks across Wintel, Mac and Linux. It also
occurred to me that if one of the available frameworks had particular
promise for use within a Python educational IDE, it might be useful to make
that choice explicitly to promote completion of the final work on it and
ultimately allow easier sharing of example code, howto's, etc.

Python is an excellent "glue" language, of course. However, I don't think
that requiring beginning programming students to learn multiple tools (that
may vary across platforms) to get the output they really want from simple
programs is a winning strategy.

> IDLE itself is a GUI of course, and I'm all in favor of
> having kids code using some intelligent interface that
> automatically color-codes key words, does other housekeeping.
> But we already have this in several forms -- and yes, there's
> always room to make it better.
> What I would never give up, in my ideal learning environment,
> is an interactive command line.  But you can get that with
> Python in Linux or DOS in a terminal window, and still make
> do.[1]

I agree that the interactive command line is a very useful feature of the
Python environment, both for working programmers and for students. My
comments were directed toward GUI elements available for use in programs,
not the IDE.

> I'm going back to my original theme:  I think we dilute the
> potential if we just dream and scheme about what Python could
> or should be, that it isn't already.[2]
> I'm sure Python will continue to evolve, but it's something
> that we could be phasing into more learning environments
> right now, today -- with 0.0 enhancements.
> I think putting out ideas about how Python needs to be
> tweeked (or even overhauled) in this or that way, before
> knuckling down to the real work of integrating it into
> the curriculum, is to let oneself off the hook to easily.
> It's like saying "3 years from now, when Python X.X
> comes out, then maybe we can...".  I really don't have
> much interest in such speculations, personally.

Guido's original CP4E proposal included testing Python in education "as is,"
development and testing of an education-oriented IDE, and consideration of
changes to the language itself if such changes appeared to be important for
educational uses. It seems to me that all of these elements, along with ways
to promote immediate adoption of Python in the curriculum, are appropriate
for discussion in the list. I don't think anyone is advocating waiting for
any particular development process if you have, or can create, a good
opportunity to put Python into the curriculum now.

Jim Harrison
Univ. of Pittsburgh