TITLE: Bad Habits and Haphazard Design
AUTHOR: Eugene Wallingford
DATE: February 27, 2015  3:37 PM
DESC: 
-----
BODY:
<P ALIGN="right"><EM>
   With an expressive type system for its teaching <BR/>
   languages,
   <A HREF="http://www.htdp.org/">
      HtDP</A>
   could avoid this problem to some <BR/>
   extent, but adding such rich types would also take <BR/>
   the fun out of programming.
</EM></P>

As we approach the midpoint of the semester, Matthias Felleisen's
<A HREF="http://www.ccs.neu.edu/home/matthias/OnHtDP/turing_is_useless.html">
   Turing Is Useless</A>
strikes a chord in me.  My students have spent the last two months
learning a little Racket, a little functional programming, and a
little about how to write data-driven recursive programs.  Yet bad
habits learned in their previous courses, or at least unchecked by
what they learned there, have made the task harder for many of them
than it needed to be.

The essay's title plays off the Church-Turing thesis, which asserts
that all programming languages have the same expressive power.
This powerful claim is not good news for students who are learning
to program, though:

<BLOCKQUOTE><EM>
 Pragmatically speaking, the thesis is completely useless at best
 -- because it provides no guideline whatsoever as to how to
 construct programs -- and misleading at worst -- because it
 suggests any program is a good program.
</EM></BLOCKQUOTE>

With a Turing-universal language, a clever student can find a way
to solve any problem with <EM>some</EM> program.  Even uninspired
but persistent students can tinker their way to a program that
produces the right answers.  Unfortunately, they don't understand
that the right answers aren't the point; the right program is.
Trolling StackOverflow
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2015-02.html#e2015-02-21T11_11_13.htm">
   will get them a program</A>,
but too often the students don't understand whether it is a good
or bad program in their current situation.  It just works.

I have not been as faithful to the HtDP approach this semester as
I probably should have been, but I share its desire to help
students to design programs systematically.  We have looked at
design patterns that implement specific strategies, not language
features.  Each strategy focuses on the definition of the data
being processed and the definition of the value being produced.
This has great value for me as the instructor, because I can
usually see right away why a function isn't working for the
student the way he or she intended: they have strayed from the
data as defined by the problem.

This is also of great value to some of my students.  They want
to learn how to program in a reliable way, and having tools that
guide their thinking is more important than finding yet another
primitive Racket procedure to try.  For others, though "garage
programming" is good enough; they just want get the job done
right now,
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2015-02.html#e2015-02-24T15_03_20.htm">
   regardless of which muscles they use</A>.
Design is not part of their attitude, and that's a hard habit
to break.  How use doth breed a habit in a student!

Last semester, I taught intro CS from what Felleisen calls a
traditional text.  Coupled that experience with my experience so
far this semester, I'm thinking a lot these days about how we can
help students develop a design-centered attitude at the outset of
their undergrad courses.  I have several blog entries in draft
form about last semester, but one thing that stands out is the
extent to which every step in the instruction is driven by the
next cool programming construct.  Put them all on the table,
fiddle around for a while, and you'll make something that works.
One conclusion we can draw from the Church-Turing thesis is that
this isn't surprising.  Unfortunately, odds are any program created
this way is not a very good program.

~~~~~

(The sentence near the end that sounds like Shakespeare is.  It's
from <EM>The Two Gentlemen of Verona</EM>, with a suitable change
in noun.)
-----