[Edu-sig] Re: Python Programming: An Introduction to ComputerScience

[John Zelle]

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