TITLE: In Programming Style, as in Most Things, Moderation
AUTHOR: Eugene Wallingford
DATE: January 05, 2010  3:25 PM
DESC: 
-----
BODY:
As I prepare for a new semester of teaching programming
languages, I've been enjoying getting back into
functional programming.  Over break, someone somewhere
pointed me toward a set of blog entries on why
<A HREF="http://prog21.dadgum.com/54.html">
   functional programming doesn't work</A>.
My first thought as I read the root entry was, "Just
use Scheme or Lisp", or for that matter any functional
language that supports mutation.  But the author
explicitly disallows this, because he is talking about
the weakness of <EM>pure</EM> functional programming.

This is common but always seems odd to me.  Many of
the arguments one sees against FP are against "pure"
functional programming: all FP, all the time.  No one
ever seems to talk in the same way about stateful
imperative programming in, say, C.  No one seems to
place a purity test on stateful programming: "Try
writing <EM>that</EM> without any functions!".
Instead, we use state and sequencing and mutation
throughout programs, and then selectively use
functional style in the parts of the program where
it makes sense.  Why should FP be any different?
We can use functional style throughout, and then
selectively use state where it makes sense.

Mixing state and functions is the norm in imperative
programming.  The same should be true when we
discuss functional programming.  In the Lisp world,
it is.  I have occasionally read Lispers say that
their big programs are about 90% functional and 10%
imperative.  That ratio seems a reasonable estimate
for the large functional programs I have written,
give or take a few percent either way.

Once we get to the point of acknowledging the
desirability of mixing styles, the question becomes
which proportion will serve us best in a particular
environment.  In game programming, the domain used
as an example in the set of blog entries I read,
perhaps statefulness plays a larger role than 10%.
My own experience tells me that whenever I can
emphasize functional style (or tightly-constrained
stateful style, a l&aacute; objects), I am usually
better off.  If I have to choose, I'll take 90:10
functional over 90:10 imperative any day.

If we allow ourselves to mix styles, then solving the
author's opening problem -- making two completely
unrelated functions interdependent -- becomes
straightforward in a functional program: define the
functions (or doppelgangers for them) in a closure
and 'export' only the functions.  To me, this is an
improvement over the "pure" stateful approach, as it
gives us state and dependent behavior <EM>without</EM>
global variables mucking up the namespace of the
program or the mindshare of the programmer.

Maybe part of the problem lies in how proponents of
functional programming pitch things.  Some are surely
overzealous about the virtues of a pure style.  But
I think as much of the problem lies in how limited
people with vast experience and deep understanding of
one way to think feel when they move outside their
preferred style.  Many programmers still struggle
with object-oriented programming in much the same
way.

Long ago, I learned from
<A HREF="http://www.cincomsmalltalk.com/userblogs/ralph/blogView">
   Ralph Johnson</A>
to encourage people to think in terms of programming
<B>style</B> rather than programming <B>paradigm</B>.
Style implies choice and freedom of thought, whereas
paradigm implies rigidity and single-mindedness.  I
like to encourage students to develop facility with
multiple styles, so that they will feel comfortable
moving seamlessly in and out of styles, across borders
whenever that suits the program they are writing.
It is better for what we build to be defined by what
we need, not our limitations.

(That last is a turn of phrase I learned from the book
<A HREF="http://www.amazon.com/exec/obidos/tg/detail/-/0961454733/qid=1100876829/">
   Art and Fear</A>,
which I have
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-11.html#e2004-11-19T10_10_14.htm">
   referenced</A>
a couple of times before.)

I do take to heart one piece of advice derived from
<A HREF="http://prog21.dadgum.com/18.html">
   another article</A>
in the the author's set of articles on FP.  People who
would like to see functional programming adopted more
widely could help the cause by providing more guidance
to people who want to learn.  What happens if we ask a
professional programmer to rewrite a video game (the
author's specialty) in pure FP, or

<BLOCKQUOTE><EM>
... just about any large, complex C++ program for that
matter[?]  It's doable, but requires techniques that
aren't well documented, and it's not like there are
many large functional programs that can be used as
examples ...
</EM></BLOCKQUOTE>

First, both sides of the discussion should step away
from the call for pure FP and allow a suitable mix
of functional and stateful programming.  Meeting in
the middle better reflects how real programmers
work.  It also broadens considerably the set of
FP-style programs available as examples, as well as
the set of good instructional materials.

But let's also give credence to the author's plea.
We should provide better and more examples, and do
a better job of documenting the functional programming
patterns that professional programmer needs.  <EM>How
to Design Programs</EM> is great, but it is written
for novices.  Maybe <EM>Structure and Interpretation
of Computer Programs</EM> is part of the answer, and
I've been excited to see so many people in industry
turning to it as a source of professional development.
But I still think we can do better helping non-FP
software developers make the move toward a functional
style from what they do now.  What we really need is
the functional programming equivalent of the Gang of
Four book.
-----