Reading 1988 Book Introduction to Functional Programming
Finished reading Introduction to Functional Programming by Richard Bird and Philip Wadler. The first edition. Published in 1988. This book is so old it’s not listed even on the authors’ university homepages and wikipedia entries. There is a 1998 version using Haskell that is listed. But I hadn’t read a programming book in a while, someone on twitter had mentioned this book, PDF was available, so I read it. Here are a few impressions.
First of all, I don’t think of myself as techie. I cannot. It wouldn’t be based on facts. I have seen too many better techies. It has depressed me over time. It’s a typical case of people being sometimes unhappy because they cannot reconcile how screwed up their lives are compared to their expectations. But actually, technology has not even been a passion. While I don’t know what can be called a passion, I think it could be something that interests you on a sufficiently longer term basis, and that you acquire somewhat deeper mastery in. In that sense, passion should not be arrived upon in a hurry. So maybe technology will become my passion. Anyway one primary reason I want to read, and occasionally write about topics related to technology is that I would like it to occupy more of my mind than many other topics. And as with many other areas of life, there’s this thing: ‘We are all in the gutter, but some of us are looking at the stars.’ Now you must have read this ‘not a techie’ disclaimer here many times. Why do I have it on my technology related posts? Well, there’s a character written by PuLa (named To in the book Vyakti Ani Valli). The character says something like: ‘Does a person who applies talcum powder on his face feel that he looks fair because of the powder whereas in reality he is not? Of course he doesn’t.’ I would not like to live with misconceptions like those. Your own self is the easiest one to fool. Hence the disclaimer every now and then. But I do have some perceptions, opinions about technology.
With that preamble, here are some of my impressions about the book and some related areas.
The 1988 book by Bird and Wadler covers some basic concepts which are mainstream now and you see those covered elsewhere. But it is fun (and at times irritating) to read formal definitions in a somewhat closer to mathematics than programming style. You know when you define currying, foldright with symbols, etc. I won’t consider the book worth while if you have read a functional programming language book. But sometimes changing the perspective (language-maths) helps. In that sense a decent read.
And now for something completely different:
I don’t like when people pick a small area in an ecosystem and become Bible-salesman-like fanatic about it. I have heard about no-carb diets, long distance running, global warming just as much as I have heard about haskell and going cloud-native. I had become (~2011-15) quite fanatic about refactoring, agile, TDD, etc. I am not saying that these are bad things. What’s bad is being dogmatic about those. Worse is when it treads into the murky waters and gives rise to (self-) righteousness and cancel culture.
Engineering is not purity. It is pragmatism. However much software craftsmanship, category theory, monads, clojure excite you, ideas and technologies like these are tools to better meet business needs. But there are pockets in IT people gravitate towards- e.g. emacs, agile, unix, etc. Mainly people do so because there is merit in these pockets and they do like cherry soda.
Functional programming has been one such pocket for some time. You can, of course, go back to von Neumann, Alonzo Church, lisp. But in large scheme of things it is not very old if you limit to multi-core processors, delayed release of Java 8 era, etc. People behave missionary like when it comes to pure functions, loops, declarative, referential transparency, tail-call, values/ value objects, pattern-matching, list-comprehensions, lazy evaluations, monoids, currying, map, reduce, filter, etc.
I have written functional programs- in java, scala, scheme, clojure, erlang, elixir, JS, and to some extent even in haskell. And I have consumed a lot of material advocating functional programming. And thought process wise, it does make you think differently. But you have to manage state, integrate with other systems, etc. So it’s worth repeating that engineering is pragmatism. Immutability and purely functional data structures are ok but things work better if they are made usable (like in clojure, and later elsewhere). Also, in my opinion static typing works better but then- as far as functional programming with static typing is concerned- there could be some compromises you may have to live with.