[Haskell-cafe] Interesting new user perspective

Jonathan Cast jonathanccast at fastmail.fm
Fri Oct 10 18:07:43 EDT 2008


On Fri, 2008-10-10 at 22:49 +0100, Andrew Coppin wrote:
> Jonathan Cast wrote:
> > Newcomers flounder because they expect to keep programming the same way
> > they always have.
> 
> _Some_ newcommers flounder because they expect Haskell to be just 
> another VB / C++ / Java / whatever. (Do we really want to encourage 
> these people to be learning Haskell in the first place?)

Absolutely not.  That's my point.

> Others it seems 
> flounder simply because Haskell completely changes almost all the rules 
> about programming, and they end up not knowing which way is up.

Are you sure teaching I/O first (or starting with an ugly, unreadable
heavily imperative straight translation of C++/Perl/Ruby) is the best
way to help these people?

The Haskell community *is* committed to teaching people good functional
design.  You can see it every day on this list.  But I don't really see
the relevance here.

> I have 
> far more sympathy with these latter people.
> 
> As I say, teaching the language syntax and the standard library 
> functions it's going to help much on its own. You need to give these 
> people some idea of what the high-level game plan is.

OK, here's the high-level game plan:

1) Figure out what your program's major types are --- just what the
names are.
2) Decide what operations you need on them.
3) Pick a domain (or functor) corresponding to each type constant,
together with implementations of your selected operations for them.
4) Derive a set of laws governing your operations, that you're going to
expect to hold for your implementation.

Now, you have an API, and (implicitly) a class of mathematical models of
that API.  This class comes with a notion of `isomorphism' (or,
technically, logical relation), between models that is required to
preserve your type constants and operations.  You have one model already
(step 3); now you need to create another one (step 5) which will be more
efficient when translated to machine code or interpreted on the
computer.

5) Design a Haskell data type for each type constant, and implement
Haskell functions for each operation. These may or may not be similar to
your domains and operations from step 3, but there should be an
isomorphism or logical relation between them.

Now, you have an implementation, and can start work on an interface.

6) Pick an environment to work in (direct X11 programming, wxHaskell,
the console, .NET, HTML over HTTP, etc.)
7) Decide what user-level operations you want to provide.
8) Decide, for each operation, what the effect of that operation should
be in terms of your underlying state (from steps 1 and 3).
9) Implement each step as a function from the old state to the new one,
using your implemented API from step 5.
10) Combine the steps into a comprehensive UI, using whatever
composition methods are available in your environment.

At each step, feel quite free to go back and revise your work at
previous ones (but be sure to continue making progress!)

An ideal tutorial would probably guide the user through these steps, in
turn; note that I/O *definitely* comes after most of the code has been
written.

> I think you need 
> to show people that you can use Haskell to do normal, ordinary stuff

Ordinary in the sense that it's common in programming tutorials, of
course.  *Real* programming mostly doesn't use printf and fget for I/O,
even in C.

> before you start showing off the more exotic things. (Obviously, you 
> need to choose your examples carefully. Anything moderately complex

Anything at all, really.  You can paper this over by just not explaining
what this `IO' type constant is doing in their programs, but I don't
think that actually helps.

jcc




More information about the Haskell-Cafe mailing list