Sailing Instead of Rowing

Meanderings on Haskell and Lazy Evaluation

Image from: https://www.etsy.com/listing/1549420762/langtian-signed-chinese-school-ink

I have written about Haskell before and I was honestly pursuing it then. Work-life put me on some side quests and I struggled to find a fast path, the right blog or the right book. I felt that what I wanted is more than understanding how to write Functors and Applicatives. More importantly, I really want to understand Monads from the point of view of meaning and design.

Having come back to this journey, I am happy to say that I find Graham Hutton’s Programming in Haskell, 2 edition to be a good balance of getting through the concepts and revealing Haskell’s powers in a readable fashion. In addition, one has plenty of chances to code along with the examples and do the exercises.

I am not rushing this, I want to let in sink in. I am almost 25% of the way in but I am in the foothills, it will get steeper. Yet, what does this have to do with sailing?

Life is most skillfully lived when one sails a boat rather than rowing it. It’s more intelligent to sail than to row.

~ Alan Watts explaining Taoism’s principle of Wu Wei

This is also known as “go with the flow”, a good way to get somewhere without burning yourself out. In this spirit, a small insight came to me while reading this example:

factors :: Int -> [Int]
factors n = [x | x <- [1 .. n], n `mod` x == 0]

prime :: Int -> Bool
prime n = factors n == [1, n]

It is a naive prime test and at first (coming from a less declarative world) I assumed that the call to factors n would evaluate first and waste time computing more than was needed to fail the test. However, the author reminded me that

[Deciding] that a number such as 15 is not prime does not require the function prime produce all of its factors, because under lazy evaluation the result False is returned as soon as any factor other than one or the number itself is produced[.]

This means as soon a partial result is computed such that

<partial> == [1, n]

is False the computation is stopped.

It was at this point that I realized how powerful a declarative and lazy language can be. Furthermore, I realized I will do better with this journey if I simply assume this property of Haskell is true and go along with it.

I then saw something else here, an intuitive conclusion that this symbolic style of computation and thinking is about meaning. It lacks direct mechanical sympathy while lazy evaluation under the hood provides that.

Following on that, I saw Turing Machines as rowing and Declarative/Lambda Calculus style programming as sailing. However, just sailing doesn’t come for free. What do I give up? Absolute and direct control. Every step, every variable access… a state machine marching across a “tape” that I know intimately and command absolutely.

I guess I would say, for now I don’t want to go to the effort of being in that level of control. I would rather reach that deeper understanding I mentioned at the start by sailing there.