Explaining with Haskell

For a long time, my impression of software was that code is always a dirty thing. The design of a system or the concept of an algorithm may be beautiful, but manifestation of an idea into executable reality via “programming” is the undignified transformation of hope into something metallic that is full of clutter, rot, and shame. At best, carefully designed “clean” code could minimize the clutter. I did not recognize this perspective as a problem; it was simply the way things were.

I don’t imagine my story is uncommon among those who have ended up in Haskell: after a computer science program full of Java and C, I found myself shifting from language to language looking for something easier to use. A more tractable medium in which to work more effectively. Technology that could, on the regrettable occasions when we must go underground and play the Morlock, allow us to spend less time there and not make so many mistakes.

We started Type Classes with the broad purpose of teaching Haskell. We knew that, realistically, the typical consumer of Haskell content is already a programmer and has some background in general computing concepts, and so the easiest thing to do would have been to write only for that audience. But we have bigger hopes for Haskell, and if we’re going to see more people learn it as their first language, then it has to be taught alongside some of the general material that new programmers need.

The Web was an obvious choice for a subject of study because it seems that most career programmers, like it or not, sooner or later end up working on a web application. And to this day I still have never seen a programming framework that lets you write a web application without understanding what the Web is. Many of us get by with only a partial understanding of what goes on when a web browser makes a request, but we and our projects suffer for it. And so the Web Servers course started off at a very basic level. What does an operating system’s interface for network communication look like? Sockets need byte strings, but we have character strings; what is the difference and how do we convert between them?

Then I began reading RFC 7230. I had referred to that document before, but never really read through it. As I read, I transcribed the specification into code, and before long had an unsophisticated web server. The best word I have to describe this experience is “transcription” because it didn’t feel dirty enough to be “programming”. Developing this course is what truly convinced me that I want to stick with Haskell or something like it for the foreseeable future, not because the code was surprisingly easy to write, but because the code is direct and illuminating. Its meaning is plain and denotational. It is not a struggle to see how the code implements the HTTP protocol; instead, the code serves as helpful assistance in explaining the protocol.

We’re pleased to announce that this content is also available in our second book, Sockets and Pipes, now for sale in early access on Leanpub! The first release contains 4 of a planned 16 chapters. These first chapters are mostly new content expanding further on the foundational concepts of character encodings and sockets, and the remaining chapters on HTTP will be more closely based on the lessons from the Type Classes course. Like our first book, Finding Success, each chapter ends with exercises, and solutions to exercises are explained in an appendix at the end of the book.

A huge thank you to all of our subscribers and readers who make this content possible.