Perspectives on learning and using Haskell

[ajb at spamcop.net]

G'day all.

Quoting Graham Klyne <GK at ninebynine.org>:

> But I also wonder if this is a sign that the XP approach to test-led
> development isn't being followed faithfully.  Theoretically (as I
> understand XP), the tests *are* the specification.  And things that aren't
> exposed can't be part of the specification, can they?

I don't understand XP this way.  The tests are, at best, part of the
specification of a module or component.  However, the specification of
the system as a whole is partially embodied in use cases and, ultimately,
the on-site customer.

> In practice, I think that there's a slight tension here:  tests may embody
> the specification, but they also embody some knowledge of the way the code
> works, and (I occasionally find) some may be created to provide a finer
> granularity of information about how the code is *mis*functioning.

Don't you sometimes wish you had a Haskell coverage analysis tool? :-)

> Which leads to a question:  I've been thinking that the "white box" tests
> may be better served by test expressions coded *within* the module
> concerned.

That's not a bad idea, but there is a problem with this, IMO.  When
programs get big, the cost of compiling becomes very significant.

Assume for a moment that the size of a program grows linearly over its
lifetime, that the cost of compiling a program is at least linear in
the size of the source code, that recompilations happen regularly and
that hardware is not upgraded.  (The last assumption is true in many
real-world cases; often, build machines are kept "frozen" to minimise
the risk of OS/compiler/etc changes introducing changes in the
produced software.)

A little thought shows that the cost of compiling this program over
its lifetime is quadratic in its final size.  It's a subtle cost because
it's amortised over the lifetime of the software, but reducing the cost
of a single compilation pass really does pay off.  It follows that
introducing code which is immediately thrown away in most cases is
probably the wrong thing for many software development tasks.

Cheers,
Andrew Bromage