Real World Haskell

We received a number of great submissions within hours of posting our request for suggestions for a library to develop bindings for in the FFI chapter. Thanks to everyone who contributed.

After looking over the alternatives, we’ve decided to use PCRE as the example. Even though there already exist useful bindings to PCRE, it’s still a good choice for teaching about the FFI, for a number of solid reasons.

• It’s small: its header file is only 300 lines long, and contains plenty of comments. We can thus cover its API almost completely, giving a thorough picture of how to build useful bindings.
• There’s no doubt that it’s both useful and portable.
• Its C API requires that users allocate and free objects manually. We can thus demonstrate how to eliminate the need to manually track objects in the Haskell bindings, through the use of finalisers.
• We can start off simply, with bindings to Haskell’s String type, and then show how to improve performance by using ByteStrings.
• It provides a callback facility, so we demonstrate inversion of control: not only how to call C from Haskell, but how to call Haskell code from C.

For teaching purposes, that’s a pretty compelling set of features. Thanks once more to those who submitted their ideas!

Update 2008-05-12: We’ve decided to go with PCRE. Thanks for all of your suggestions!

We’re about to start on one of our last chapters, on using Haskell’s foreign function interface (FFI). We’re currently kicking around candidate C libraries that we can use as examples to write bindings for.

So far, we’ve thought about PCRE and sqlite: each is small, widely used, and portable to Linux, OS X, and Windows. On the slightly negative side, there already exist Haskell bindings for each (in fact, PCRE has three different libraries with bindings to it).

If you’d like to suggest some other library that meets the criteria of a small API, an open source license, portability to the three major platforms, and general niftiness, please leave us a comment with your idea. Thanks!

A number of reviewers have asked about chapters that have not yet been heavily commented upon. Here’s a table that indicates the current state of play for all of the beta chapters we have published so far. It’s ranked by the ratio of the number of paragraphs in a chapter to the number of comments for that chapter. A lower ratio indicates that a chapter needs more attention.

I’ve marked chapters 1 through 11 in bold. If a chapter is marked bold and has a low ratio, we’d be really happy to see it get more attention, because we’ll be shipping it to the production team soon. Thanks!

Chapter	Paragraphs	Comments	Ratio
6. Writing a library	227	31	0.14
17. Monad transformers	151	32	0.21
16. Programming with monads	222	51	0.23
15. Monads	338	121	0.36
5. Functional programming	382	140	0.37
11. Code case study: parsing a binary data format	170	64	0.38
10. I/O case study: a library for searching the filesystem	207	78	0.38
14. Data structures	189	82	0.43
9. Case study: regular expressions and file name matching	174	89	0.51
8. Input and output	218	152	0.70
4. Defining types, streamlining functions	301	284	0.94
22. Working with databases	76	77	1.01
7. Using typeclasses	98	122	1.24
3. Types and functions	274	392	1.43
1. Why functional programming? Why Haskell?	131	209	1.60
2. Getting started	148	342	2.31

I had a lot of fun talking about concurrent and parallel programming last night. Thanks to Keith Fahlgren for organising the event, to Twitter’s Alex Payne for making space available, and to everyone who turned up and asked questions.

With any luck, Keith will have the video of the talk up in a few days. I spoke for about 45 minutes, and took questions afterwards for a further 75 (really!). The atmosphere was great, and the questions that followed very engaging.

I’ve posted the slides from the talk to Slideshare.

If you prefer, or Slideshare acts balky (unfortunately common), you can download the slides in one of several offline formats:

• PDF
• Apple Keynote
• Powerpoint (zipped)

They’re CC-licensed, so have fun using them for your own purposes.

(Oh, and credit for the Haskell logo in the slides is due to Ketil Malde.)

I’ve just posted two new beta chapters for review:

• 5. Functional programming
• 6. Writing a library

Also, we’ll soon be starting to feed chapters into O’Reilly’s production pipeline. If you’ve been following our progress, but holding off on reading and reviewing draft chapters, this would be a great time to start taking a look if you want to influence the final result.

Now that we have all of chapters 1 through 11 posted, please submit any comments you have by Thursday, May 15.

Yes, this does mean that the endgame is approaching! We still have a few chapters left to write, and art and production issues to sort out, so I can’t give you an exact publication date (or even an exact month) yet, but things are going well. Expect to see more public beta draft chapters within the next few weeks!

Next Thursday evening, May 8, I’ll be talking about concurrent and multicore programming in Haskell. The meeting is being organised by BayFP, and space is being generously donated by Twitter.

The meeting will be at 7:30pm, in the South Park neighbourood of San Francisco. For more details, including directions, see the BayFP blog posting.

BayFP talks are usually recorded and posted somewhere within a few days, so I’ll follow up with links to the video and slides afterwards.

Good evening! We’ve just published first drafts of some more new chapters:

• 1. Why functional programming? Why Haskell?
• 16. Programming with monads
• 17. Monad transformers (this will probably be in a later position in the final table of contents)

We’re particularly interested in feedback on chapter 1, because it’s the first place that many undecided readers will flip to, and we want to make as strong a positive impression as we can.

This evening, we’ve put up five new first-draft chapters for review:

• 10. I/O case study: a library for searching the filesystem
• 11. Code case study: parsing a binary data format
• 14. Data structures
• 15. Monads
• 22. Working with databases

Enjoy!

We’ve had draft chapters of the book available for almost six months now, and the other day, our editor asked if we were getting much value out of the comment system that we built.

I think that in terms of the ratio of work put in to benefit received, the comment system has been one of the best small hacks I’ve ever written. It took me about 20 hours to build, and another 4 to debug. So far, we’ve received about 3,600 comments. This number makes me positively giddy with delight.

As to the quality of the comments, our readers are incredibly generous with the time they put into closely reading our text, and just as thoughtful with what they have to say about it. Feedback runs the gamut from small stuff like typo corrections, though suggestions for rewording sections, to comments that some material is redundant, boring, or confusing.

In my case, for a handful sections where I rushed through my first drafts (probably late at night), some of the feedback has been pretty strident. I’ve been surprised to find that I don’t at all mind being told that something I wrote sucks: this just gives me, er, sufficient motivation to go back and turn it into something decent. (There’s no doubt, though, that opening up the early writing process to this kind of inspection requires a strong constitution.)

As for our response to comments, my own way of dealing with them has changed over time. Initially, I was overwhelmed by their sheer quantity. Although I read every comment, I rarely responded to any individually, because it seemed like such a huge mountain. After a while, though, my attitude changed: I concluded that if someone was going to take the trouble to tell me something they thought was important, the least I could do was acknowledge what they said and thank them. That’s now my usual default. (I can’t tell if readers like this, but hey, I’m doing it for me.)

Building an RSS feed has more than paid off: our readers use the comment system to engage in conversations with each other, going back and forth about who’s got a better idea for presenting a particular idea.

All of this is a long-winded way of saying that I think the comment system has been a smashing success so far. We listen very carefully to what you have to say. To all of you who have given us feedback so far: thanks!

A number of reviewers have asked for some way to hold general discussions about the book, outside of the comment system. I’ve created a mailing list, discuss at realworldhaskell.org, which you can subscribe to if you’re interested. The list isn’t moderated, but only members can post.