TITLE: Functional Programming Moments
AUTHOR: Eugene Wallingford
DATE: February 08, 2006  2:23 PM
DESC: 
-----
BODY:
I've been having a few Functional Programming Moments
lately.  In my Translation of Programming Languages
course, over half of the students have chosen to write
their compiler programs in Scheme.  This brought back
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-10.html#e2004-10-04T17_44_46.htm">
   fond memories</A>
of a previous course in which one group chose to build
a content management system in Scheme, rather than one
of the languages they study and use more in their other
courses.  I've also been buoyed by reports from professors
in courses such as Operating Systems that some students
are opting to do their assignments in Scheme.  These
students seem to have really latched onto the simplicity
of a powerful language.

I've also run across a couple of web articles worth noting.
Shannon Behrens wrote the provocatively titled
<A HREF="http://www.linuxjournal.com/article/8850">
   Everything Your Professor Failed to Tell You
   About Functional Programming</A>.
I plead guilty on only one of the two charges.  This
paper starts off talking about the seemingly inscrutable
concept of monads, but ultimately turns to the question
of why anyone should bother learning such unusual ideas
and, by extension, functional programming itself.  I'm
guilty on the count of not teaching monads well, because
I've never taught them at all.  But I do attempt to make
a reasonable case for the value of learning functional
programming.

His discussion of monads is quite nice, using an analogy
that folks in his reading audience can appreciate:

<BLOCKQUOTE><EM>
Somewhere, somebody is going to hate me for saying this,
but if I were to try to explain monads to a Java programmer
unfamiliar with functional programming, I would say: "Monad
is a design pattern that is useful in purely functional
languages such as Haskell.
</EM></BLOCKQUOTE>

I'm sure that some folks in the functional programming
community will object to this characterization, in ways
that Behrens anticipates.  To some, "design patterns"
are a lame crutch object-oriented programmers who use
weak languages; functional programming doesn't need
them.  I like Behrens's response to such a charge
(emphasis added):

<BLOCKQUOTE><EM>
I've occasionally heard Lisp programmers such as Paul
Graham bash the concept of design patterns.  To
such readers I'd like to suggest that the concept
of designing a domain-specific language to solve
a problem and then solving that problem in that
domain-specific language is itself a design pattern
that makes a lot of sense in languages such as Lisp.
<STRONG>Just because design patterns that make sense
in Java don't often make sense in Lisp doesn't detract
from the utility of giving certain patterns names
and documenting them for the benefit of ... less
experienced programmers.</STRONG>
</EM></BLOCKQUOTE>

His discussion of why anyone should bother to do the
sometimes hard work needed to learn functional
programming is pretty good, too.  My favorite part
addressed the common question of why someone should
willingly take on the constraints of programming
without side effects when the freedom to compute
both ways seems preferable.  I have written on this
topic before, in an entry titled
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-03.html#e2005-03-30T10_44_45.htm">
   Patterns as a Source of Freedom</A>.
Behrens gives some examples of self-imposed cosntraints,
such as encapsulation, and how breaking the rules
ultimately makes your life harder.  You soon realize:

<BLOCKQUOTE><EM>
What seemed like freedom is really slavery.
</EM></BLOCKQUOTE>

Throw off the shackles of deceptive freedom!  Use Scheme.

The second article turns the seductiveness angle upside
down.
<A HREF="http://blogs.msdn.com/sriram/archive/2006/01/15/lisp_is_sin.aspx">
   Lisp is Sin</A>,
by Sriram Krishnan, tells a tale being drawn to Lisp the
siren, only to have his boat dashed on the rocks of
complexity and non-standard libraries again and again.
But in all he speaks favorably of ideas from functional
programming and how they enter his own professional
work.

I certainly second his praise of 
<A HREF="http://www.norvig.com/">
   Peter Norvig</A>'s
classic text
<A HREF="http://www.norvig.com/paip.html">
   Paradigms of AI Programming</A>.

<BLOCKQUOTE><EM>
I took advantage of a long weekend to curl up
with a book which has been called the best book
on programming ever -- Peter Norvig's <I>Paradigms
of Artificial Intelligence Programming: Case Studies
in Common Lisp</I>.  I have read <I>SICP</I> but
the 300 or so pages I've read of Norvig's book have
left a greater impression on me than SICP.  Norvig's
book is definitely one of those 'stay awake all night
thinking about it' books.
</EM></BLOCKQUOTE>

I have never heard anyone call Norvig's book the best
of all programming books, but I have heard many folks
say that about <I>SICP</I> --
<A HREF="http://mitpress.mit.edu/sicp/full-text/book/book.html">
   Structure and Interpretation of Computer Programs</A>,
by Abelson and Sussman.  I myself have
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-04.html#e2005-04-20T11_16_13.htm">
   praised Norvig's book</A>
as "one of my favorite books on programming", and it
teaches a whole lot more than just AI programming or
just Lisp programming.  If you haven't studied, put
it at or near the top of your list, and do so soon.
You'll be glad you did.

In speaking of his growth as a Lisp programmer,
Krishnan repeats an old saw about the progression
of a Lisp programmer that captures some of the
magic of functional programming:

<BLOCKQUOTE><EM>
... the newbie realizes that the difference between
code and data is trivial.  The expert realizes that
all code is data.  And the true master realizes that
all data is code.
</EM></BLOCKQUOTE>

I'm always heartened when a student takes that last
step, or show that they've already been there.  One
example comes to mind immediately:  The last time I
taught compilers, students built the parsing tables
for the compiler by hand.  One student looked at the
table, thought about the effort involved in translating
the table into C, and chose instead to write a program
that could interpret the table directly.  Very nice.

Krishnan's article closes with some discussion of how
Lisp doesn't -- can't? -- appeal to all programmers.
I found his take interesting enough, especially the
Microsoft-y characterization of programmers as one of
"Mort, Elvis, and Einstein".  I am still undecided just
where I stand on claims of the sort that Lisp and its
ilk are too difficult for "average programmers" and thus
will never be adoptable by a large population.  Clearly,
not every person on this planet is bright enough to do
everything that everyone else does.  I've learned that
about myself many, many times over the years!  But I am
left wondering how much of this is a matter of ability
and how much is a matter of needing different and better
ways to teach?  The monad article I discuss above is a
great example.  Monads have been busting the chops of
programmers for a long time now, but I'm betting that
Behrens has explained it in a way that "the average
Java programmer" can understand it and maybe even have
a chance of mastering Haskell.  I've long been told by
colleagues that Scheme was too abstract, too different,
to become a staple of our students, but some are now
choosing to use it in their courses.

Dick Gabriel once said that talent does not determine
how good you can get, only how fast you get there.
Maybe when it comes to functional programming, most of
us just take too long to get there.  Then again, maybe
we teachers of FP can find ways to help accelerate the
students who want to get good.

Finally, Krishnan closes with a cute but "politically
incorrect analogy" that plays off his title:

<BLOCKQUOTE><EM>
Lisp is like the
<A HREF="http://en.wikipedia.org/wiki/Bond_girl">
   villainesses</A>
present in the Bond movies.  It seduces you with its
sheer beauty and its allure is irresistible.  A fleeting
encounter plays on your mind for a long, long time.
However, it may not be the best choice if you're looking
for a long term commitment.  But in the short term, it
sure is fun!  In that way, Lisp is...sin."
</EM></BLOCKQUOTE>

Forego the demon temptations of Scheme!  Use Perl.

Not.
-----