TITLE: Programming in Context: Digital History
AUTHOR: Eugene Wallingford
DATE: October 04, 2011  4:43 PM
DESC: 
-----
BODY:
Last April
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-04.html#e2011-04-06T19_10_50.htm">
   I mentioned</A>
<EM>The Programming Historian</EM>, a textbook aimed at a specific
set of non-programmers who want or need to learn how to program in
order to do their job in the digital age.  I was browsing through
<A HREF="http://niche-canada.org/programming-historian/">
   the textbook</A>
today and came across a paragraph that applies to more than just
historians or so-called applied programmers:

<BLOCKQUOTE><EM>
Many books about programming fall into one of two categories: (1)
books about particular programming languages, and (2) books about
computer science that demonstrate abstract ideas using a
particular programming language.  When you're first getting
started, it's easy to lose patience with both of these kinds of
books.  On the one hand, a systematic tour of the features of a
given language and the style(s) of programming that it supports
can seem rather remote from the tasks that you'd like to
accomplish.  On the other hand, you may find it hard to see how
the abstractions of computer science are related to your specific
application.
</EM></BLOCKQUOTE>

I don't think this feeling is limited to people with a specific
job to do, like historians or
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-10.html#e2011-10-02T17_16_32.htm">
   economists</A>.
Students who come to the university intending to major in Computer
Science lose patience with many of our CS1 textbooks and CS1
courses for the very same reasons.  Focusing too much on all the
features of a language is overkill when you are just trying to
make something work.  The abstractions we throw at them don't
have a home in their understanding of programming or CS yet and so
seem, well, too abstract.

Writing for the aspiring applied programmer has an advantage over
writing for CS1: your readers have something specific they want
to do, and they know just what it is.  Turkel and MacEachern can
teach a subset of several tools, including Python and Javascript,
focused on what historians want to be able to do.  Greg Wilson
and his colleagues can teach what scientists want and need to
know, even if
<A HREF="http://pragprog.com/book/gwpy/practical-programming">
   the book</A>
is pitched more broadly.

In CS1, your students don't have a specific task in mind and do
eventually need to take a systematic tour of a language's features
and to learn a programming style or three.  They do, eventually,
need to learn a set of abstractions and make sense of them in
the context of several languages.  But when they start, they are
much like any other person learning to program: they would like
to do <EM>something</EM> that matters.  The problems we ask them
to solve
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-03.html#e2005-03-14T14_47_54.htm">
   matter</A>.

Guzdial, Ericson, and their colleagues have used
<A HREF="http://coweb.cc.gatech.edu/mediaComp-teach">
   media computation</A>
as context in which to learn how to program, with the idea that
many students, CS majors and non-majors alike, can be enticed
to manipulate images, sounds, and video, the raw materials out
of which students' digital lives are now constructed.  It's not
quite the same -- students still need to be enticed, rather than
starting with their own motivation -- but it's a shorter leap to
caring than the run-off-the-mill CS textbook has to make.

Some faculty argue that we need a CS0 course that all students
take, in which they can learn basic programming skills in a
selected context before moving onto the major's first course.
The context can be general enough, say, media manipulation or
simple text processing on the web, that the tools students learn
will be useful after the course whether they continue on or not.
Students who elect to major in CS move on to  take a systematic
tour of a language's features, to learn about OO or FP style,
and to begin learning the abstractions of the discipline.

My university used to follow this approach, back in the early
and mid 1990s.  Students had to take a one-year HS programming
course or a one-semester programming course at the university
before taking CS1.  We dropped this requirement when faculty
began asking, why shouldn't we put the same care into teaching
low-level programming skills in CS1 as we do into teaching CS0?
The new approach hasn't always been as successful as we hoped,
due to the difficulty of finding contexts that motivate students
as well as we want, but I think the approach is fundamentally
sound.  It means that CS1 may not teach all the things that it
did when the course had a prerequisite.

That said, students who take one of our non-majors programming
courses, C and Visual Basic, and then move decide to major in
CS perform better on average in CS1 than students who come in
fresh.  We have work to do.

Finally, one sentence from <EM>The Programming Historian</EM>
made me smile.  It embodies the "programming for all" theme
that permeates this blog:

<BLOCKQUOTE><EM>
Programming is for digital historians what sketching is for
artists or architects: a mode of creative expression and a
means of exploration.
</EM></BLOCKQUOTE>

I once said that being able to program is like
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-01.html#e2010-01-13T19_18_10.htm">
   having superhuman strength</A>.
But it is both more mundane and more magical than that.
For digital historians, being able to program means being
able to do the mundane, everyday tasks of manipulating text.
It also gives digital historians a way to express themselves
creatively and to explore ideas in ways hard to imagine
otherwise.
-----