[Edu-sig] Topics for CS2

[David MacQuigg]

At 08:45 AM 1/20/2009 -0800, kirby urner wrote:
>On Tue, Jan 20, 2009 at 1:52 AM, David MacQuigg wrote:

>> There may be some misunderstanding as to my purpose in writing this chapter.
>...
>
>On a scale of 1-10, overriding __del__ in the process of doing
>subclass instance counting in a parent class, is like 8 or 9,
>especially where you bring __mro__ into it.  So yes, I see your desire
>to include arcana.  You're being respectful of your students' already
>high level of initiation.

All this is in the "Advanced Topics" section at the end.  I probably should make that a separate chapter to avoid any distraction.  The part I expect students at the CS2 level to understand is in the first 12 pages, and that should be free of arcana.

...

>But in Python, everything is a snake, a live object, including numbers
>like 1 and 2, and they have knowledge of addition and multiplication
>"in their bones" (__ribs__).  When you go 1 * 2, that's not a space
>ship, bristling with static methods from on high, from the alien
>"knows operations" land, that's invoking an innate ability of the
>integer type.
>
>It's a change in gestalt, especially if you start with the old one.

...

>> As for making OOP a "revelation", I think that is the wrong way to teach it, especially for non-CS students.  I much prefer to treat it as just another way to encapsulate pieces of a program, a way that is very natural when you are modeling objects in the real world, and can be beneficial even when there is no parallel in the real world - the benefit flowing from the extra flexibility you have in encapsulation.  That is something all engineers will understand.  The "revelation" approach completely turned me off when I first read about OOP in the early 90's.  As a skeptical engineer, I was left with the impression that OOP, polymorphism, etc., was a pile of hype, and there was nothing there I couldn't do in FORTRAN, BASIC, or C.  It wasn't until I started using Python in 2002, that I saw the benefits.  I like that Python doesn't mystify OOP, or push it the way Java does, but just makes it a natural thing to do.
>>
>
>Yes, that transition to OOP was upsetting as a paradigm change.  I
>went through it on the xBase path, following dBase II (derived from
>some JPL language) through its winged migration, fork off to Clipper,
>FoxPro, buyout by Microsoft and Borland, FoxPro for Windows, Visual
>FoxPro.  The full OO paradigm came across, unlike for the VB crowd,
>who didn't get that until later.  This all happened in my little world
>*before* I ever wrote a line of Python (plus I got to Java first).
>APL was the first computer language I ever learned (loved it), then
>FORTRAN (yawn).
>
>However, the real benefit of OO is it hooks to natural language, where
>students in human languages, like Sumerian, like Greek, already know
>about nouns, verbs and adjectives as parts of speech.  OO is all about
>noun.verb() and noun.adjective.  Then with have these little cartoons
>about sharing pointers (names) to objects and we're done, they're
>convinced there's a real grammar here, a logic, and dive in, happy to
>still be in the humanities, no talk of "computer hardware" need apply
>(though it's handy to have).  This isn't "hyping" so much as
>"bridging".  In industry, it's about town-gown relations, where "town"
>is an administrative layer atop cube farmers, and "gown" is IT.  With
>ORM, we're finally starting to get admin enrolled in seeing it from
>IT's point of view, whereas SQL by itself was just not friendly
>enough.
>
>OO makes computing more personable.  To have busy administrators see
>'self' as like "a little ego with a personal __dict__ clipboard" is
>not "dumbing it down" is rather taking advantage of well-worn patterns
>in grammar, leveraging what we've already got.  It's efficient.  Don't
>just say "is a", say "I am a".  This isn't just cute, it's a
>conceptually smart way to think about a hospital, school or airport
>(objects all).  But that's me to busy administrators, not you to
>enrolled electrical engineers.  Different audiences = different
>patter, we both know that.

I think many of us who grew up with the "old gestalt" had a hard time with the transition to OOP.  Maybe the old gestalt still includes administrators, but I would be surprised if it includes high-school students.  It did include engineering students a few years ago, when we had a junior-level course in OOP taught in Smalltalk, so the students would be forced to break out of their old habits and do everything in the style of OOP.  We still have that course, but now the pre-requisite is a course in Java, and it has morphed to more software-engineering and less pounding on the necessity of OOP.

It seems that the "new gestalt" should not require breaking old habits.  Objects should be introduced early, the noun.verb syntax is simple, and there is little need for motivation, revelation, or elaborate analogies by the time the students get to crafting their own objects.  That seems to be the approach taken by newer texts, and it would have been beneficial for me also.  It really wasn't the difficulty of the OOP paradigm that held us back, but the awkwardness of the languages, which perhaps created a need to force-feed and over-sell the idea of OOP, which turned off pragmatic folks like myself.  We still have that awkwardness in our intro Java courses, but it seems to have been accepted as a minor inconvenience ("Just memorize this stuff, we'll explain it later.").

I put together a sequence of Python examples for the transition to OOP, and added them to my collection for CS2 ( http://ece.arizona.edu/~edatools/index_classes.htm ).  The emphasis is practical benefits, not any attempt to sell OOP.  The principle is that you chose the level of structure that is right for your problem, bearing in mind that real-world problems tend to grow, so a little extra structure at the beginning often saves time in the end.  The final example shows how Python can do everything that Java does, including private parts, and interface definitions.

>Thank you for making your work public and open source in this way.
>You are kind to offer it up for comments and to handle the feedback
>graciously, especially given my many different biases.

And thank you for your constructive criticism, which is always appreciated.

-- Dave