TITLE: Thinking in Types, and Good Design
AUTHOR: Eugene Wallingford
DATE: May 07, 2014  3:39 PM
DESC: 
-----
BODY:
Several people have recommended Pat Brisbin's
<A HREF="http://robots.thoughtbot.com/thinking-in-types">
   Thinking in Types</A>
for programmers with experience in dynamically-typed languages
who are looking to grok Haskell-style typing.  He wrote it
after helping one of his colleagues of mine was get unstuck
with a program that "seemed conceptually simple but resulted
in a type error" in Haskell when implemented in a way similar
to a solution in a language such as Python or Ruby.

This topic is of current interest to me at a somewhat higher
level.  Few of our undergrads have a chance to program in
Haskell as a part of their coursework, though a good number
of them learn Scala while working at a local financial tech
company.  However, about two-thirds of undergrads now start
with a one or two semesters of Python, and types are something
of a mystery to them.  This affects their learning of Java and
colors how they think about types if they take my course on
programming languages.

So I read this paper.  I have two comments.

First, let me say that I agree with my friends and colleagues
who are recommending this paper.  It is a clear, concise, and
well-written description of how to use Haskell's types to
think about a problem.  It uses examples that are concrete
enough that even our undergrads could implement with a little
help.  I may use this as a reading in my languages course
next spring.

Second, I think think this paper does more than simply teach
people about types in a Haskell-like language.  It also gives
a great example of how thinking about types can help
programmers create better designs for their programs, even if
they are working in an object-oriented language!  Further, it
hits right at the heart of the problem we face these days,
with students who are used to working in scripting languages
that provide high-level but very generic data structures.

The problem that Brisbin addresses happens after he helps his
buddy create type classes and two instance classes, and they
reach this code:
<PRE>
    renderAll [ball, playerOne, playerTwo]
</PRE>

<TT>renderAll</TT> takes a list of values that are
<TT>Render</TT>-able.  Unfortunately, in this case, the
arguments come from two different classes...  and Haskell does
not allow heterogeneous lists.  We could try to work around
this feature of Haskell and "make it fit", but as Brisbin
points out, doing so would cause you to lose the advantages
of using Haskell in the first place.  The compiler wouldn't
be able to find errors in the code.

The Haskell way to solve the problem is to replace the generic
list of stuff we pass to <TT>renderAll</TT> with a new type.
With a new <TT>Game</TT> type that composes a ball with two
players, we are able to achieve several advantages at once:
<UL>
<LI> create a polymorphic <TT>render</TT> method for
     <TT>Game</TT> that passes muster with the type checker  </LI>
<LI> allow the type checker to ensure that this element of
     our program is correct  </LI>
<LI> make the program easier to extend in a type-safe way  </LI>
     our program is correct  </LI>
<LI> and, perhaps most importantly, <EM>express the intent of
     the program more clearly</EM> </LI>
</UL>

It's this last win that jumped off the page for me.  Creating
a <TT>Game</TT> class would give us a better <B>object-oriented</B>
design in his colleague's native language, too!

Students who become accustomed to programming in languages like
Python and Ruby often become accustomed to using untyped lists,
arrays, hashes, and tuples as their go-to collections.  They
are oh, so, handy, often the quickest route to a program that
works on the small examples at hand.  But those very handy
data structures promote sloppy design, or at least enable it;
they make it easy not to see very basic objects living in the
code.

Who needs a <TT>Game</TT> class when a Python list or Ruby array
works out of the box?  I'll tell you: you do, as soon as you
try to almost anything else in your program.  Otherwise, you
begin working around the generality of the list or array,
writing code to handle special cases really aren't special
cases at all.  They are simply unbundled objects running wild
in the program.

Good design is good design.  Most of the features of a good
design transcend any particular programming style or language.

So:  This paper is a great read!  You can use it to learn
better how to think like a Haskell programmer.  And you can
use it to learn even if thinking like a Haskell programmer
is not your goal.  I'm going to use it, or something like it,
to help my students become better OO programmers.
-----