TITLE: Exercises in Exercises in Style
AUTHOR: Eugene Wallingford
DATE: May 21, 2013  3:05 PM
DESC: 
-----
BODY:
I just registered for
<A HREF="https://thestrangeloop.com/">
   Strange Loop 2013</A>,
which doesn't happen until this fall.  This has become a popular
conference, deservedly so, and it didn't seem like a good idea
to wait to register and risk being shut out.

One of the talks I'm looking forward to is by
<A HREF="https://twitter.com/cristalopes">
   Crista Lopes</A>.
I mentioned Crista in
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2012-09.html#e2012-09-28T15_59_40.htm">
   a blog entry from last year's Strange Loop</A>,
for a talk she gave at OOPSLA 2003 that made an analogy between
programming language and natural language.  This year, she will
give a talk called
<A HREF="https://thestrangeloop.com/sessions/exercises-in-style">
   Exercises in Style</A>
that draws inspiration from a literary exercise:

<BLOCKQUOTE><EM>
Back in the 1940s, a French writer called Raymond Queneau wrote
an interesting book with the title Exercises in Style featuring
99 renditions of the exact same short story, each written in a
different style.  This talk will shamelessly do the same for a
simple program.  From monolithic to object-oriented to
continuations to relational to publish/subscribe to monadic to
aspect-oriented to map-reduce, and much more, you will get a
tour through the richness of human computational thought by
means of implementing one simple program in many different ways.
</EM></BLOCKQUOTE>

If you've been reading this blog for long, you can image how
much I like this idea.  I even checked
<A HREF="http://en.wikipedia.org/wiki/Exercises_in_Style">
   Queneau's book</A>
out of the library and announced on Twitter my plan to read it
before the conference.  From the response I received, I gather
a lot of conferences attendees plan to do the same.  You gotta
love the audience Strange Loop cultivates.

I actually have a little experience with this idea of writing
the same program in multiple styles, only on a much smaller
scale.  For most of the last twenty years, our students have
learned traditional procedural programming in their first-year
sequence and object-oriented programming in the third course.
I taught the third course twice a year for many years.  One
of things I often did early in the course was to look at the
same program in two forms, one written in a procedural style
and one written in OOP.  I hoped that the contrast between the
programs would help them see the contrast between how we think
about programs in the two styles.

I've been teaching functional programming regularly for the
last decade, after our students have seen procedural and OO
styles in previous courses, but I've rarely done the "exercises
in style" demo in this course.  For one thing, it is a course
on languages and interpreters, not a course on functional
programming <EM>per se</EM>, so the focus is on getting to
interpreters as soon as possible.  We do talk about differences
in the styles in terms of their concepts and the underlying
differences (and similarities!) in their implementation.  But
I think about doing so every time I prep the next offering of
the course.

Not doing "exercises in style" can be attractive, too.  Small
examples can mislead beginning students about what is important,
or distract them with concepts they'd won't understand for a
while.  The wrong examples can damage their motivation to learn.
In the procedural/object-oriented comparison, I have had
reasonable success in our OOP course with a program for simple
bank accounts and a small set of users.  But I don't know how
well this exercise would work for a larger and more diverse set
of styles, at least not at a scale I could use in our courses.

I thought of this when
<A HREF="https://twitter.com/kaleidic">
    @kaleidic</A>
tweeted, "I hope @cristalopes includes an array language among
her variations."  I do, too, but my next thought was, "Well,
now Crista needs to use an example problem for which an array
language is reasonably well-suited."  If the problem is not well
suited to array languages, the solution might look awkward, or
verbose, or convoluted.  A newcomer to array languages is left
to wonder, "Is this a problem with array languages, or with the
example?"  Human nature as it is, too many of us are prone to
protect our own knowledge and assume that something is wrong
with the new style.

An alternative approach is to get learners to suspend their
disbelief for a while, learn some nuts and bolts, and then
help them to solve bigger problems using the new style.  My
students usually struggle with this at first, but many of them
eventually reach a point where they "get" the style.  Solving
a larger problem gives them a chance to learn the advantages
and disadvantages of their new style, and retroactively learn
more about the advantages and disadvantages of the styles they
already know well.  These trade-offs are the foundation of a
really solid understanding of style.

I'm really intrigued by Queneau's idea.  It seems that he uses
a small example not to teach about each style in depth but
rather to give us a taste.  What does each style <EM>feel</EM>
like in isolation?  It is up to the aspiring writer to use this
taste as a starting point, to figure out where each style might
take you when used for a story of the writer's choosing.

That's a promising approach for programming styles, too, which
is one of the reasons I am so looking forward to Crista's talk.
As a teacher, I am
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-09.html#e2007-09-13T20_23_19.htm">
   a shameless thief of good ideas</A>,
so I am looking forward to seeing the example she uses, the way
she solves it in the different styles, and the way she presents
them to the crowd.

Another reason I'm looking forward to the talk is that I love
programs, and this should be just plain fun.
-----