On 31/01/07, Michael T. Richter <ttmrichter@gmail.com> wrote:

I disagree with this part. Books written by committee lack cohesion unless they have an overbearing editor at the helm. What I've seen on the Wiki as regards idioms, standard practices, etc. -- and this is true of every language wiki I've ever seen -- is one proposed answer and then a chain of "but you could do it this way instead" with ever-increasingly-obscure ways of doing things. Which would be the precise opposite of what a "Haskell for the Working Programmer" book should be like.

I agree up to a point - there's a huge risk that increasingly "advanced" solutions will obscure the point. A reasonable amount of editorial control could keep this in check, though.

A book like this should be clear, straightforward and provide an introduction to Haskell for a working programmer, but an introduction that gets said programmer up and on the job quickly. After using the (possibly even less than ideal) solutions provided in the book, the reader can then comfortably hone the newfound skills provided.

I do like the idea of developing a table of contents first and backfilling it, though. I would amend the process, however, to avoid the WikiBloat that seems to inevitably follow when documentation projects get too open. Instead of Wikifying it, I'd suggest instead that a "call for proposals" be put on the mailing list. "I'm working on a chapter dealing with database programming. I need to know how to do <insert whatever> in Haskell. Could anybody interested in helping please submit some commented, functioning code for possible inclusion?" Then the submissions could be made by email (and possibly even discussed on-list) and the editor/author of the book can take an executive decision and choose one if there are competing camps.

Possibly. From my own point of view, though, I'm usually only after fairly simple snippets of code - certainly not enough for a book chapter (although they could be grouped into chapters by topic).

Here's a slightly extended example: a key snippet for me would be "execute a query against a database and get the results". Naively, I see this as an IO action, much like reading a file. So I'd expect something like

    connect :: String -> String -> String -> IO dbHandle
    connect user password db = {- some magic to connect and give me a DB handle -}

    close :: dbHandle -> IO ()
    close dbh = {- magic to close the handle -}

    query :: dbHandle -> String -> IO [String]
    query dbh sql = {- more magic to do the query and return results -}

I'd use this as

    do dbh <- connect "system" "manager" "my_oracle_db"
        results <- query dbh "select * from all_users"
        close dbh
        return results

(I'd see it as being in the IO monad, so that I can intersperse other IO actions. Maybe that's not necessary, but that's a different recipe - how do I intersperse actions in 2 different monads - that I'd class as quite advanced).

It's not remotely functional, it's likely not to be "the best way" and it's probably making the advanced users squirm, but that's not the point. It fits my beginner's mental model - I'm new to Haskell, I've grasped the concept of IO and probably a little bit of how monads are great for structuring code (I'd probably write my own "auto-close" control structure for this - and soon after, find that it already exists!) but I'm not really worried. To me, Haskell is brilliant for slinging data around in clever ways. So this is just annoying boilerplate I need to get the data into my program - it doesn't even have to be efficient, because I'm only grabbing a few tens of rows here (getting data lazily would be a *separate* recipe, that I'd look at for the million-row query I'll try once I feel like getting more advanced).

The point of this is that to me, pulling data out of databases is *boring*. The interesting bit is manipulating that data - and that's the bit that drew me to Haskell because other languages make the data manipulation tedious and boring as well. So I want easily tailorable snippets of code to get me past the boring stuff - I'm busy learning interesting things elsewhere in Haskell at the moment.

Of course, in the above you could easily substitute any number of tasks for "querying a database". Grabbing web pages, displaying a GUI, etc. The point is the same - they aren't (yet) the interesting bit.

Sorry, that went on a bit - I hope it was useful nevertheless.

Paul.