TITLE: Follow Up to Recent Entry on Intro Courses
AUTHOR: Eugene Wallingford
DATE: January 09, 2008  4:31 PM
DESC: 
-----
BODY:
After writing my
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2008-01.html#e2008-01-03T15_25_09.htm">
   recent entry</A>
on some ideas about CS intro courses gleaned from a few
of the columns and editorials in the latest edition of
<EM>inroads</EM>, I had a few stray thoughts that seem
worth expressing.

<EM>On Debate</EM>

I always feel a little uneasy when I write a piece like
that.  It comments specifically on an article written by a
<A HREF="http://www.cs.cofc.edu/~manaris/">
   CS colleague</A>,
and in particular criticizes some of the ideas expressed
in the article.  Even when I include disclaimers to the
effect that I really like an article, or respect the
author's work, there is a chance that the author will
take offense.  That happens in the case even of more
substantial written works, and I think that the looser,
more "thinking out loud" nature of a blog only compounds
the chance of a misunderstanding.

I certainly mean no offense when I write such pieces.
Almost always, I am grateful for the author having
triggered me to think and write something down.  And
always I intend for my articles to play a part in a
healthy academic debate on an issue that both the
author and I think is important.

Without healthy discussion of what we do -- and sometimes
even contentious debate -- how can we hope to know whether
we are on a good path?  Or get onto a good path in the
first place?  Debate, or the friendlier "discussion" is
one of the best ways we have for getting feedback on our
thinking and for improving our ideas.

I like healthy discussion, even contentious debate, because
I don't mean or take personal offense.  I've always liked
a good hearty discussion, but still I am indebted to my
<A HREF="http://www.cse.msu.edu/~sticklen/">
   graduate advisor</A>
for modeling how academics approach ideas.  In meetings
of our research group and in seminars, he was often like
a bulldog, challenging claims and offering counterarguments.
At times, he could be contentious, and often the room
became a lot hotter as he, I, and a couple of likewise
combative fellow grad students went at it.

But those discussions were always about ideas.  When the
meeting was up, the discussion was over, and we all went
back to being friends and colleagues.  My advisor never
held a grudge, even if I spent an hour telling him he was
wrong, wrong, wrong.  He enjoyed the debate, and knew that
we all were getting better from the discussion.

Sometimes we have to work not to take personal offense,
and to express our thoughts in a way that won't cause
offense to a reasonable person.  Sometimes, we even have
to adjust our approach to account for the people in the room.
But the work is worth it, and debate is necessary.

<EM>On Exciting Bright Minds</EM>

When deciding how to teach our intro courses, we need to ask
several questions.  What works best for our student population
overall?  What helps weakest students learn as much of value
as they can?  What helps our strongest students see the
exciting ideas of computing deeply and come to love the power
they afford us?

My dream is that we can offer all of our students, but especially
our brightest ones, the sort of excitement that Jon Bentley felt,
as he writes in his <EM>Communications of the ACM</EM> 50th
anniversary piece
<A HREF="http://portal.acm.org/citation.cfm?id=1327477">
   In the realm of insight and creativity</A>.
The pages of each issue ignited a young mind that helped to
define our discipline.  Maybe our courses can do the same.

<EM>On Simplicity</EM>

In my article, I withheld comment on one of the "language war"
elements of Manaris's argument, namely the argument for using
a simpler language.  In the editorial spirit of his article,
I will share my own opinions, based almost wholly in personal
preference and anecdote.

I remain a strong believer that OOP can be the foundation of
a solid CS curriculum, but Java and certainly C++ are not the
best vehicles for learning to program.  I agree with Manaris
that a conceptually simpler language is preferred.  He cites
Alan Kay, whom regular readers here know I cite frequently.
I agree with Bill and Alan!  Then again, Smalltalk or a variant
thereof might be an even better choice for CS1 than Python.
It has a simpler grammar, no goofy indentation rules no
strange <TT>__this__</TT> operator, ... but it is quite
different from most mainstream languages in feel, style, and
environment.  Scheme?  Can't get much simpler that that.  We
have learned, though, that simplicity itself can create a
different sort of overload difficulty for students while
learning.  Many folks are successful teaching Scheme early,
and I wish we had more evidence on Smalltalk's use in CS 1.

Conceptual simplicity is a good thing, but it is but one of
several forces at play in the decision.

For what it's worth, as I mentioned in the same entry, we
will be offering a Python-based media computation CS 1
course this semester.  I am eager to see how it goes, both
on its own and in comparison to the Java-based media comp
CS 1 we taught once before.

<EM>On Patterns</EM>

Finally, Manaris quotes Alan Kay on the non-obvious ideas
that can trip up a novice programmer, some which are

<BLOCKQUOTE><EM>
... like the concept of the arch in building design: very
hard to discover, if you don't already know them.
</EM></BLOCKQUOTE>

I do not advocate hanging novices up on non-obvious ideas,
but it occurs to me that instruction driven by elementary
patterns would address this difficulty head-on.  Sometimes,
a concept we think obvious is not so to a student, and
other times we <STRONG>want</STRONG> students to encounter
a non-obvious idea as a part of their growth.  Patterns
are all about communicating such ideas, in context, with
explanation of some of the thinking that underlies their
utility.
-----