TITLE: Programming Healthily
AUTHOR: Eugene Wallingford
DATE: February 29, 2020 11:19 AM
DESC: 
-----
BODY:

... or at least differently.  From
<A HREF="https://onezero.medium.com/how-google-got-its-employees-to-eat-their-vegetables-a2206820d90d">
   Inside Google's Efforts to Engineer Its Food for Healthiness</A>:

<BLOCKQUOTE><EM>
 So, instead of merely changing the food, Bakker changed the
 foodscape, ensuring that nearly every option at Google is
 healthy -- or at least healthyish -- and that the options
 that weren't stayed out of sight and out of mind.
</EM></BLOCKQUOTE>

 This is how I've been thinking lately about teaching functional
 programming to my students, who have experience in procedural
 Python and object-oriented Java.  As with deciding what we eat,
 how we think about problems and programs is mostly unconscious,
 a mixture of habit and culture.  It is also something intimate
 and individual, perhaps especially for relative beginners who
 have only recently begun to know a language well enough to solve
 problems with some facility.  But even for us old hands, the
 languages and mental tools we use to write programs can become
 personal.  That makes change, and growth, hard.

 In my last few offerings of our programming languages course, in
 which students learn Racket and functional style, I've been
 trying to change the programming landscape my students see in
 small ways whenever I can.  Here are a few things I've done:
<UL>
<LI> I've shrunk the set of primitive functions that we use in the
     first few weeks.  A larger set of tools offers more power and
     reach, but it also can distract.  I'm hoping that students can
     more quickly master the small set of tools than the larger set
     and thus begin to feel more accomplished sooner.  </LI>
<BR/>
<LI> We work for the first few weeks on problems with less need for
     the tools we've moved out of sight, such as local variables
     and counter variables.  If a program doesn't really benefit
     from a local variable, students will be less likely to reach
     for one.  Instead, perhaps, they will reach for a function
     that can help them get closer to their goal.  </LI>
<BR/>
<LI> In a similar vein, I've tried to make explicit connections
     between specific triggers ("We're processing a list of data,
     so we'll need a loop.") with new responses ("<TT>map</TT> can
     help us here.").  We then follow up these connections with
     immediate and frequent practice.  </LI>
</UL>

 By keeping functional tools closer at hand, I'm trying to make it
 easier for these tools to become the new habit.  I've also noticed
 how the way I speak about problems and problem solving can subtly
 shape how students approach problems, so I'm trying to change a
 few of my own habits, too.

 It's hard for me to do all these things, but it's harder still
 when I'm not thinking about them.  This feels like progress.

 So far students seem to be responding well, but it will be a while
 before I feel confident that these changes in the course are
 really helping students.  I don't want to displace procedural or
 object-oriented thinking from their minds, but rather to give them
 a new tool set they can bring out when they need or want to.
-----