On 31/01/07, Michael T. Richter <[EMAIL PROTECTED]> 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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
