Over the last couple of weeks, I've traded emails with Bryan O'Sullivan (@bos31337 on Twitter),Don Stewart (@donsbot on Twitter), and John Goerzen (@jgoerzen on Twitter), the authors of Real World Haskell
. We've talked about their book, why Haskell matters, and why you shouldn't be afraid of monads (at least in RWH).
By the way, this book is another case of O'Reilly doing the right thing. Real World Haskell is available online at book.realworldhaskell.org/read/. The online book includes a reader comment tool which will help the book continue to improve. Thanks O'Reilly for making things like this happen.
How real world is Haskell?
Bryan The tools and libraries around Haskell have increased greatly in both number, robustness, and capability over the past few years. There has been a concerted push within the community to make it easier to develop and deploy new code. As a result, Haskell is in the enviable position of becoming a "stealth" real world language, where a team that adopts it can hope to steal a march on people using less productive languages.
Don The Haskell language, toolchain and libraries have really converged on "industrial strength" over the last few years. The Haskell community, built from three pillars: the academics who designed the language, the open source community driving production of code, and the industrial users applying the result and feeding back new ideas, is really buzzing. Drop by the #haskell IRC channel to get a feel for the energy and excitement around the language.
To get a feel for the growth around the language, you only need to hang out at CUFP (the Commercial Users of FP workshop), where we have people talking about their day jobs doing hardware design in Haskell, controlling hydraulic equipment, running financial infrastructure, deploying web apps, writing high assurance systems and more.
To complement this growth in industrial use, the open source community has been churning out new libraries and tools. Almost a thousand Haskell packages have appeared on Hackage — Haskell's CPAN — in the last 20 months. From delicious, flickr and twitter bindings, to Perl compilers, p2p network systems and filesystems. The growth and diversity of code produced has been amazing.
John Very. I am using it at work at a lawn mower manufacturer. Haskell has been involved in innovation in distributed version control systems (darcs) and Perl 6 as well.
I directly am using it for database and web work, LDAP tools, parsing and data conversion, and just about any other routine programming task I might have. I am very happy with the Haskell programs in our setup at work, and have a greater confidence in their reliability than I have in the tools we've implemented with other languages.
LDAP, data munging, web stuff ... these sound like some of the grotty, sys-admin things that I tend to do, but a lot of sys admins are going to be scared away by CSisms like 'type inference', and 'functional programming', or worse 'eschewing side-effects' (yeah, the last one's not your fault). Are sys admins a reasonable target audience for your book? If so, how can they get the most out of it without being impaled on a monad or something?
John This question gets to the heart of what RWH is about — bridging that gap. The preface to the book really gets to the heart of it: why Haskell is interesting for sysadmins, what it has to offer them, and what benefits they can expect by learning it.
Some of these things aren't terribly hard concepts. We can explain type inference as simply "the compiler figures out what the types are by how they're used". Monads are powerful, and might be scary because they've been presented that way. But do get Real Work done, you don't really have to care about them much (though they can make your life easier if you do).
I really think that laziness is the hardest concept to grasp. People are so used to telling a computer, "do task x, then task y, then task z if both of them worked." Haskell programs read more like, "OK, computer. If you ever need to do task x, here's how. You figure out if you need to do it." This is obviously a grotesque oversimplification of both perspectives, but my point is that it's a huge mindset shift. But it makes some hard problems expressible quite easily. We talk about functions in Haskell — really — in terms of whether or not they can work with infinite lists.
So, what we do, is show people. Not just "laziness does foo", but we write code to demonstrate it. Real, working code that compiles and runs and solves real problems. We invite comparisons to other languages, and explain our approach.
You don't have to have a CS degree to be a programmer, and Haskell is no exception. I maintain that it's not harder, just so different that people that have spent a lot of time in the imperative, non-FP world have a few new ideas to soak up.
And really, that's the best part of Haskell, in my opinion. Even if you don't use it, it's a mind-blowing language. I think that it would be truly hard to learn all about Haskell and then go back to using Java or something.
So to answer your question: Haskell has a lot of utility to a sysadmin, and that's my primary use for it, and yes sysadmins are a reasonable target for this book.
Don Well, John's a sys admin, so he obviously finds Haskell entirely suitable. But I was pondering this question, and asked our guru administrator, Paul Heinlein, at Galois why he was reading RWH, and what he hoped to get from it:
There are times when I'll write something in, say, Perl that requires several CPAN modules, some of which may be pretty non-standard. Moving that code to a different machine forces me to install those modules yet again (and perhaps again and again).
I've often yearned for a language with a compiler than can produce real system binaries (not something that requires a runtime system like Java) that I can ship to various systems. The language I've had in mind would work at a higher level than C, be available on Linux/Unix platforms, have decent library support (ala CPAN), and have an accessible developer/user community.
Haskell looks like it might fit that bill. I won't know for sure until I've done a lot more work, but it's certainly looks worth the effort.
So, portability, native code, high level. The same reasons Linspire used Haskell for their distro scripts.
Bryan's comment that 'a team that adopts [Haskell] can hope to steal a march on people using less productive languages' makes me think of Paul Graham and Lisp. Are we going to be seeing "On Haskell" on the shelf at our local bookseller in 10 years?
John I think it's safe to say that there will be more Haskell books in the future as the language's popularity continues to expand. I haven't read "On Lisp", so I can't comment on that specifically.
Bryan I haven't read Graham's book (though I've done a lot of Lisp hacking), but from skimming the blurb, it sounds quite similar to our own. I know that more Haskell books will be appearing in the years to come, and I hope that they will span the range from the practical to the highly advanced.
What have you done to get past the 'ivory tower' feel that so many books, tutorials, and blogs about haskell have?
Don We've focused on the "in the trenches" category of programming tasks we all do in Haskell: hacking databases, network programming, parsing binary protocols, writing web apps, designing GUIs, and writing parallel and concurrent programs. The kind of stuff we do in Haskell in our day jobs, but where the techniques hadn't been gathered in a single place, until now.
We're kind of spoilt as authors: we got to take all that "ivory tower" research work on new language and library ideas, filter it through the open source community, and apply it to make the daily programming tasks easier and more fun.
Bryan We grounded all of our examples in code that people could download and execute, and our examples perform realistic tasks from our own experience. It's also important that none of us is a professional academic; we never ran a risk of being removed from the concerns of our fellow practical programmers.
John I still remember when I learned Haskell, and how I was frustrated that it took so long to get to I/O in some tutorials. It seemed as if people were afraid of it, or thought it unimportant.
I approached this topic from the perspective that I/O in Haskell is beautiful and powerful, that it is critical to real world use, and that we have to cover it well and pervasively. We introduce I/O in chapter 1, dedicate chapter 7 to it, and have several more chapters that deal with it extensively, directly or indirectly.
The other thing is showing people how people in business, open source, and at home, are using Haskell to solve problems. We tried to include as many full examples as we could: programs that compile, run, and do something useful. In RWH, we have things such as a barcode image processor and a podcast aggregator.
In which problem domains should programmers be looking to haskell for a better way of doing things?
Bryan It might be more helpful to turn the premise of this question around: there are just a few domains to which Haskell is not well suited, notably embedded systems and those demanding real time response. And there are remain some areas where library support is essential to making progress, for which Haskell libraries have not yet been built and would require a substantial investment of time. But for a large number of application domains, Haskell is already a good enough language for fast-turnaround productive use.
Don Four main themes come up when you look at why people are using Haskell:
- They have hard problems
- They care about correctness and robustness
- They want serious performance, while still working with a high level language
- They want to program their multicore system
Haskell's a rare beast, combining the safety of languages like Ada, with the high level abstractions of languages like Python, Ruby or Lisp (or even higher levels of abstraction..), but yet compiled down to efficient native code that competes with C. And it may be unique as the only language with those properties also targetting multicores *now*, out of the box.
Perl 6 is a great example of a "hard problem" that got easier once they started using Haskell. No on e had produced an implementation of perl6, until Audrey Tang decided to spec it out while learning Haskell. The result was Pugs, the first working Perl 6 implementation, and still the most sophisticated and feature complete implementation.
Another nice example is IVU Traffic Technologies' solver for "roster compliance" of EU bus timetabling systems. Apparently, EU bus regulations are NP-hard to comply with! So they wrote a constraint solver in Haskell to verify compliance of bus timetables, which they call from their existing C++ and Java code, ensuring that regional bus routes in the EU are on time and efficient.
Galois, where Don works, uses Haskell to design solutions to hard problems in the design of trustworthy critical systems. They use Haskell for almost all of their projects, because of the ability to combine high level language productivity, with low level performance (for things like file systems, OS kernels and network stacks), while crucially retaining the ability to build correct-by-design software, and to employ formal methods to prove correctness.
So, if you care about productivity, want to avoid bugs, need performance but want to work with a high level language, or have a multicore system, then Haskell might be a sensible choice.
John There are a great number of problem domains where it could be useful — it's a general-purpose language now, and no longer restricted to a niche.
I think of it as, in some ways, the next natural evolution of a language such as Python. Python is a great language for writing code fast, but it has some drawbacks: its lack of static typing means that type errors won't be caught until runtime, for instance.
Haskell is quick to code in, and its type inference means that type errors can be caught at compile time, even without you having to pepper code with type declarations.
But it goes deeper than the type system. The functional approach to programming has a lot of benefits, and Haskell really turns it into a modern force in programming.
So Haskell gives you speed of development, safety, and a useful paradigm. This is all good news for real world things: web sites, database tools, and the like. Nobody wants to see an exception on their website or have a critical data exchange tool crash.
What is it about Haskell that drew you to the language?
Bryan I became interested in functional programming in the late 1980s, and discovered Haskell around 1992. For me, the beauty and rigour of functional programming posed an irresistible challenge. It hasn't hurt at all that these properties lead to the development of clearer, more expressive code.
John I had been using Python for a number of years as my main "go to" language. Every so often, I like to learn a new language. I had tried OCaml, and was dissatisfied with a number of things in it (such as its I/O system). Plus it wasn't different enough for me. So I decided that Haskell looked interesting, and dove in.
So I got involved with Haskell simply because it was different than anything else I'd used.
What do you think the Haskell community can learn from other language communities?
John I'm probably not well-equipped to answer here, since I have never been deeply involved with any other language community. The Haskell community is an incredibly diverse, friendly, and intelligent place. Tools such as Hackage are clearly inspired by CPAN/CTAN.
Haskell-cafe is an amazing list in that you'll see posts such as CS Ph.D's writing about type theory to people discussing ODBC databases right next to each other. I've never seen anything like that on any other language list, and I hope we can maintain it.
Bryan Honestly, the Haskell community is in an enviable position compared to every other language I know. Between the vast amount of intellectual energy and the friendliness that people exhibit, with a community size that's big enough to get important things done but small enough that people know each other personally, I can't think of any other language that's in a better spot right now.
which is a fun read and packed with all you need to set out writing your first (and second) applications.
(rereading this one, see my review 
, which is due out in out in March of 2009. The book is about learning how to learn, and pushing yourself along the path toward a higher level of craftsmanship. While it's not Ruby-centric, I think it's the kind of book that will be widely read within Ruby circles. To get a jump on things, I've started an interview with Dave and Ade. Here's the first part:
and 
. These are books that people keep telling us changed their lives. We're not quite that ambitious. But hopefully if we introduce new software developers to ideas like software craftsmanship and show them the most powerful ideas we know of then those people can use them to change their lives.
to help me manage my day. It really helped me when systems like GTD didn't seem to fit the way I live or work.
, has a wonderful section where he talks about the importance of checklists for people who are highly skilled. The checklist is how they make sure that they don't leave instruments inside the patient when an operation develops complications or forget to wash their hands after seeing a patient who is terminally ill. His point is that tacit knowledge is easily forgotten by experts in moments of great stress but the checklists can be used by the less skilled members of a team to keep everybody honest. In fact some of my fondest memories of ThoughtWorks projects are the moments when someone I've taught TDD asks "is there a test for that?" At that point I've either been caught as I'm about to cut a corner or I've been caught applying some meta-heuristic without explaining it first. Either way everybody learns something.
.
book — which I hold in very high esteem — is predicated on the GoF design patterns, and on the constraints imposed by a statically typed language. Ruby's dynamic aspects — notably duck typing and open classes — mean that patterns such as Strategy, say, can be expressed differently, and the forces for applying those patterns will also subtly alter. That, in turn, means that some of the "moves" in Refactoring may need to be revised for Ruby. And in some cases, it means we need completely new refactorings.
, which is a re-working of Martin Fowler's original 
.