[Edu-sig] Edu-sig Digest, Vol 32, Issue 8

[Toby Donaldson]

> Dethe Elza wrote:
> > .... Back to the subject of improved turtles, I think there could be a
> > two-pronged approach. The first prong would be to provide incremental
> > improvements to the existing turtle.py (and possibly IDLE) within the
> > standard distribution...
> Along this prong, how about a list of turtle.py's deficiencies?
> I suspect this list will to a lot to assuage Art's fears of over-
> elaboration.  What I have read in the discussion is that a clear
> small interface is wanted to the internal module.

Here are the problems I had with turtle.py in the situation of
teaching it to ~500 first-year university students, most of whom
identify themselves as non-technical. I've ordered them by importance
for my purposes:

  - There's no doc strings or other documentation in the turtle.py
module itself. There is one the web page, and that certainly helps,
but it should be in turtle.py.

  - The error messages are sometimes unnecessarily confusing. For
example, you can set pen colors in about three ways, and different
kinds of errors are generated depending on the mistake you make. One
standard error message that gives examples of the correct way to set
colors would save a lot of unnecessary headaches.

  - Idle and Python don't play well together (on Windows, at least).
There are fixes, but they are still not ideal.

  - I find the turtle too powerful for my purposes. Many of the
current turtle functions can easily be implemented in terms of other
ones, and I think it's instructive for students to do that for
themselves, to learn about functional decomposition, bottom-up
programming, code re-use, etc.

  - At the same time, I would also like to have more powerful turtles
that would be useful for more powerful graphics. You know, the right
turtle for the right job. :-)

  - The name Pen is a bit confusing, since this is "turtle" graphics.
But it wasn't a major problem for me since I stuck mainly with the
non-OOP turtle commands.

One the plus side:

  - Once Python is installed, turtle.py just works (usually!). There's
no extra packages to install or options to configure. Just load and
go. Many students (and teachers!) get frustrated installing software
at home, and the "batteries included" nature of turtle.py is a win.
Dealing with installation issues can eat up a lot of time in large
courses, and so minimizing that is good.

  - It's simple, easy to understand stuff that turns out to be very
powerful. Even using multiple Pen objects proved easy for interested
students when they see even one or two examples. (My course doesn't
cover OOP, but after seeing the success of using turtle.py, it makes
sense to move that way.)

  - It's in Python. Part of the goal of the course is, at least for a
few students, to learn enough about Python to use it for practical,
real-world scripting that don't involve graphics or games. So I prefer
to stick to the language proper than to use special educational
packages. Part of this is personal taste and the culture of my
department's approach to introducing programming; I certainly do give
students special libraries and other packages (like PyGame) later in
the course, so I am admittedly "soft" on this issue, and possibly
inconsistent.

It boils down to this: turtle graphics was fun and educational for
hundreds of students. I can't think of many other things I've done in
such a class that have had such a positive impact. Fixing a few
obvious problems with turtle.py will surely only improve the
experience. Moving to a different kind of graphics or a different
turtle system might work as well or better, but I am not currently
convinced that such a move will accrue enough benefits to make it
worth the effort. I know from experience the sort of risks involved in
making changes to big courses.

I agree with those who suggested a two-pronged approach: tweak
turtle.py, and then consider the creation of bigger and better Python
education tools. I've already written a lot fo doc-strings for
turtle.py to offer to Vern, and I would willing to help out on the
second prong too; if, for example, Gregor wanted to spearhead that
starting with xturtle and friends, I'd be interested in helping out
insofar as my particular experience and needs can be of use.

Toby
--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)