Why We Are Starting a Book Club

Health-eFilings Engineering has started a book club.  We won't be discussing War and Peace, or the latest from J.K. Rowling, but some good, old-fashioned non-fiction.

I was excited to hear this proposal for a few reasons:

Growth as an organization

It's important for a company, particularly a startup, to hire talented people.  It's even more important for those talented people to refine their craft, and raise their performance and that of the whole team.

Positive peer pressure on each other to improve our skills

We've all decided to learn something, but never found time to do it.  Or burn out after a quick start.  Having the team learn together means deadlines, which means pressure, which means it's˙easier to fit into our busy schedules.

Spending more time together on not strictly work-related activities

Our team is fun to work with, but being remote, we don't get many chances to do anything but work together.  Here is a great chance for us to do something other than work together, which will help bring us together.

Discussion leading to deeper understanding and better retention

Looking at my bookshelf, I see many texts that I've read, but can't tell you much about.  Not that I didn't pay attention while reading them, just that data has been overwritten.  The fact that we will be discussing these books will make us pay closer attention, take notes, and think about the material after reading it.  I hope this will not only deeper understanding of the material, but also to better retain it.

For our first book, we are reading Haskell Programming from First Principles.  We met last week to cover Chapter 1, Lambda Calculus.  Our discussion covered a number of topics, including:

Why Lambda Calculus is Important

We discussed how Haskell is really an implementation of a typed Lambda Calculus.  Besides, the authors warn us not to skip this chapter.  We also discussed how the chapter was originally not part of the book, but was added after the authors had feedback.

Syntax of Lambda Calculus

We discussed how the syntax in chapter 1 uses a confusing a mix of mathematical syntax and non-mathematical expressions.  This particularly gets confusing when switching from expressions like x + 1 and xx, which is not "X times X".  Adjacency, instead means "function application" in lambda calculus.

Next we discussed how everything after the head is right-associative.  This, in particular, cleared up a bit for me.  Though I was confused by whether parentheses change the order of operations or indicate a division between a function and its arguments.


We reviewed combinators, discussed the S, K, and I combinators, and how they are all that is needed to build a Turing machine.  Though not explicitly mentioned in chapter 1, we discussed the Y combinator, how it is used to allow recursion using anonymous functions.  Overall, it isn't very clear, and requires one to reduce it on their own to understand it.

Beta Reduction

Probably the simplest topic we covered.  We discussed how the wording of "Applying a function to an argument" vs. our understanding of "Applying arguments to a function".  Did I mention I have an imperative programming background?


We discussed whether or not divergence is a practical outcome in calculation, and where it could occur.  One example is iterative calculations with no exit condition.  In Haskell, the idea of lazy evaluation, of an infinite list is like divergence, but a filter can be applied to limit it to a finite set.

Next we will be covering Chapter 2, Hello Haskell (and perhaps Chapter 3).  If you are learning Haskell, consider reading Haskell Programming from First Principles, and learning along with us.

About the author:

Jeff Schmitz is a Software Engineer for Health-eFilings with a passion for Ruby and an interest in Haskell since seeing the quicksort implementation.