[Edu-sig] Re: Python Programming: An Introduction
to ComputerScience
John Zelle
john.zelle at wartburg.edu
Sat Dec 13 15:59:56 EST 2003
Hello all,
I've been reading the thread about my book with great interest. All
feedback is helpful, even when I don't necessarily agree. Let me just
say that I thought Kirby's initial posting was right on target. My book
is intended as a CS1 book, not a book on Python. Because of that, I have
been a little fearful about how the book might be received in the Python
community. Kirby clearly understands the distinction being drawn, and I
appreciate the way his remarks are framed.
I am much less concerned than others about how the more advanced and/or
indiosyncratic features of Python are/might be taught. The truth is that
the tradtional core computer science sequence CS1 (Intro to
programming), C2 (Data Structures and Design), CS3 (Advanced Data
structures and Algorithms) have not been "about" language for a long
time. Even a student that goes through this sequence using a single
language, whether that be C++, Java, or Python will not acquire expert
knowledge of the language. That's simply not what these courses are
about. The point is that once a student has completed CS1/CS2, they can
pick up a good technical book and have the foundation to learn the
complete feature set of any language.
Students continue programming throughout their CS programs and in future
careers. They are constantly changing tools. With some serious early
exposure to a variety of tools (say dynamic and static languages) they
are in a better position to pick tools that are best suited for the job
at hand. A move to Java or C++ in CS2 should not be seen as "abandoning"
Python. In fact, seeing Python side-by-side with Java ususally leads my
students to want to do more Python projects (and hence learn more about
Python) in their upper-level classes. Without seeing a statically typed
language, it's hard to appreciate the elegance and flexibility of
Python. For example, when we talk about polymorphism in CS1, the
students say "of course, what's the big deal." Only when they see the
complexity of doing similar things in C++ or Java do they really
appreciate the concept.
Whatever approach one takes to the first classes, it is important to
realize that our students do not begin programming with the same
background that we have. Most of my students are not particularly
mathematically or scientifically oriented (at least at the start). And
they are concrete, not abstract thinkers. It's important that we try to
meet them where they are so that they can learn and grow with minimal
frustration. Packing more into CS1 is probably not the way to do that.
Along similar lines, Kirby's comment on abstracting geometric objects
from their realizations (see below) are absolutely right on track as a
matter of design principle. I do address this sort of decoupling toward
the end of the book (model-view architectures). However, the goal of the
graphics package is somewhat different. The purpose is to introduce
objects in a very concrete way. It is a graphics library, not a geometry
library. A Point doesn't really represent an abstract geometric point,
but a postion _in_a_window_. Similarly, the Rectangle is not a general
mathemetical abstraction, but an actual box on the screen (maybe I
should have called it "box"). Now an object on the screen has inherent
properties such as color and outline width as instrinsic properties;
whereas the mathematical abstraction does not. This is most evident in
the Line class. A Line on the screen is not really a line in the
mathematical sense---at best it would be a line segment. If you were
designing an application around the mathematical concepts you could use
the primitives of the graphics library to visually realize some of those
(so the graphics package would be analogous to the backend, not the front).
Of course, I do use the graphics package to get my students to do things
like calculating points of intersection and computing coordinate
transformations. The beauty of it is that they think they are just
drawing pretty pictures :-).
My thanks to all of you who have given me both encouragement and
criticism on this project.
--John
Kirby Urner wrote:
>Earlier I wrote:
>
>
>>When considering option (e), my attention goes to the Point class. If all
>>a Point does is hold x and y coords, then a class implementation seems
>>like overkill in Python. You could get by with built-in tuples.
>>
>>
>
>Now that I have the student CD, I see that the Point class is not just a
>holder for (x,y) values. It has some knowledge of Tk, is in fact a subclass
>of GraphicsObject, which is very Tk aware.
>
>This brings up a design pattern thread for me. My tendency over the years
>has been to write the geometric objects, such as vectors and polyhedra, in
>such a way as to deliberately keep them ignorant of any output apparatus.
>
>Then I define a "writer" that's customized to say Tk, or VRML, or POV-Ray,
>and pass the geometric objects to the writer. The writer squeezes pure
>geometric information from the things, and translates them into output
>appropriate to its medium.
>
>You can see evidence of this strategy going all the way back to 1998, when I
>was still doing this stuff in FoxPro (I hadn't learned of Python yet):
>http://www.4dsolutions.net/ocn/oop.html
>
>A consequence of this design is I've been putting what philosophers used to
>call "secondary attributes" (color, texture) in the writer, instead of in
>the geometric objects. So if I want a red tetrahedron, say, I change to
>"edge color" and "face color" properties in the writer, before passing a
>tetrahedron object to it.
>
>E.g.:
>
> >>> povwriter = povray.Povray("outfile.pov")
> >>> povwriter.cylcolor = 'Red' # secondary attribute
> >>> obj = rbf.Tetra() # get a tetrahedron
> >>> obj.draw(povwriter)
>
>But internally to obj.draw(povwriter), I'm invoking povwriter on the various
>edges, vertices and faces of my obj:
>
> def draw(povwriter):
>
> for e in self.edges():
> povwriter.edge(e)
>
> ...
>
>and like that.
>
>The upside of this design is if I go obj.draw(vrmlwriter), then the same
>object gets output in VRML syntax.
>
>In sum, when writing geometric objects to output media, there's a way to go
>wherein anything specific to the medium is saved to the "writer" object,
>while anything purely geometric, and common to all media, is saved in the
>geometric object. The pure geometry is kept separate from the messy details
>of I/O.
>
>I'm just bringing this up as a by the way. I'm not saying Zelle should have
>done this in his text book.
>
>It'd be a fruitful discussion for CS2 level course -- when we're talking
>about design patterns.
>
>Kirby
>
>
>
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig
>
>
>
>
--
John M. Zelle, Ph.D. | Wartburg College
Associate Prof. of CS | Dept. Math/CS/Physics
john.zelle at wartburg.edu | Waverly, Iowa
More information about the Edu-sig
mailing list