TITLE: Bridging the Gap Between Learning and Doing
AUTHOR: Eugene Wallingford
DATE: June 29, 2015  1:58 PM
DESC: 
-----
BODY:
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0"
       STYLE="float: right; margin-left: 3em; margin-right: 1em; margin-bottom: 2em;">
<TBODY><TR><TD>
<A HREF="http://www.stat.ucla.edu/~amelia.mcnamara/FOSP.html">
   <IMG SRC="http://www.cs.uni.edu/~wallingf/blog-images/computing/fosp-sketch.jpg"
        ALT="a sketch of bridging the gap"
        WIDTH="250"
        ALIGN="center" /></A>
</TD></TR></TBODY>
</TABLE>

I recently learned about the work of Amelia McNamara via
<A HREF="http://www.vpri.org/pdf/m2014002_robust.pdf">
   this paper</A>
published as Research Memo M-2014-002 by the Viewpoints Research
Institute.  McNamara is attacking an important problem: the gap
between programming tools for beginners and programming tools
for practitioners.  In
<A HREF="http://www.stat.ucla.edu/~amelia.mcnamara/FOSP.html">
   Future of Statistical Programming</A>,
she writes:

<BLOCKQUOTE><EM>
 The basic idea is that there's a gap between the tools we
 use for teaching/learning statistics, and the tools we use
 for <B>doing</B> statistics.  Worse than that, there's no
 trajectory to make the connection between the tools for
 learning statistics and the tools for doing statistics.  I
 think that learners of statistics should also be doers of
 statistics.  So, a tool for statistical programming should
 be able to step learners from learning statistics and
 statistical programming to truly doing data analysis.
</EM></BLOCKQUOTE>

"Learners of statistics should also be doers of statistics." --
yes, indeed.  We see the same gap in computer science.  People
who are learning to program <EM>are</EM> programmers.  They are
just working at a different level of abstraction and complexity.
It's always a bit awkward, and often misleading, when we give
novice programmers a different set of tools than we give
professionals.  Then we face a new learning barrier when we ask
them to move up to professional tools.

That doesn't mean that we should turn students loose unprotected
in the wilds of C++, but it does require that that we have a
pedagogically sound trajectory for making the connection between
novice languages and tools and those used by more advanced
programmers.

It also doesn't mean that we can simply choose a professional
language that is in some ways suitable for beginners, such as
Python, and not think any more about the gap.
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2015-06.html#e2015-06-09T14_48_25.htm">
   My recent experience</A>
reminds me that there is still a lot of complexity to help our
students deal with.

McNamara's
<A HREF="http://www.stat.ucla.edu/~amelia.mcnamara/dissertation.html">
   Ph.D. dissertation</A>
explored some of the ways to bridge this gap in the realm of
statistics.  It starts from the position that the gap should not
exist and suggests ways to bridge it, via both better curricula and
better tools.

Whenever I experience this gap in my teaching or see researchers
trying to make it go away, I think back to Alan Kay's early vision
for Smalltalk.  One of the central tenets of the Smalltalk agenda
was to create a language flexible and rich enough that it could
accompany the beginner as he or she grew in knowledge and skill,
opening up to a new level each time the learner was ready for
something more powerful.  Just as a kindergartener learns the same
English language used by Shakespeare and Joyce, a beginning
programmer might learn the same language as Knuth and Steele,
one that opens up to a new level each time the learner is ready.

We in CS haven't done especially good job at this over the years.
Matthias Felleisen and the
<A HREF="http://www.htdp.org">
   How to Design Programs</A>
crew have made perhaps the most successful effort thus far.  (See
<A HREF="http://www.ccs.neu.edu/home/matthias/OnHtDP/_SL__Not_Racket.html">
   *SL, Not Racket</A>
for a short note on the idea.)  But this project has not made a
lot of headway yet in CS education.  Perhaps projects such as
McNamara's can help make inroads for domain-specific programmers.
Alan Kay may harbor a similar hope; he served as a member of
McNamara's Ph.D. committee.
-----