It is fair to say I have a number of books I want to read. I usually just work my way through them without really mentioning them on this blog. But for books that I want to study rather than just read I thought I might try writing a blog post about each chapter.
This means for studying a chapter of a book I will 1. Makes notes on the chapter as I read it. 2. Make flash cards for Anki. 3. Write a summary for this blog.
Perhaps this is too much but I figure lets see how this goes, I can always change my mind at a later date. It will certainly make me think about each chapter with increased depth. A few random thoughts about this are:
- I may not finish the book. If I find I am not enjoying the book I may push it back for a while or just stop reading it. Having put much of the information in Anki I should be able to pick the book back up.
- It is likely I will have more than one book on the go at any one time. Again Anki should help me here. When studying at school/university you will often be managing learning multiple topics at once. I see no reason to stop once you leave those institutions.
- Books that are not available for free I will veer towards summary rather than detail. I don’t want people to read my chapter summary and decide they are getting enough from those to not buy the book. Books are awesome and writing one should be encouraged.
On Lisp is a fairly famous book about some of the more intermediate/advance topics in lisp. Written by Paul Graham and published in 1993, it is currently available for free online. I am hoping that investing time in reading this book will push forward my very basic understanding of lisp. Either way it has been on my To Read list for a very long time.
The prologue of the book read in a fairly standard way for a programming language book. This book is going to change the way you program and the language “X” is great. I have read this type of things many times so I am not surprised that it is here. What else would you write in a Programming language book?
I should add it is clear that even back than Paul Graham was a very good writer, or had a very good editor.
Chapter one of most technical books are usually a fairly easy read and this was no exception.
This chapter is about positioning Lisp as the ideal programming language for bottom up programming. Because of the facilities of the languages you can easily mould the language to the problem you are trying to solve. By evolving a program design the idea is it takes less time to write and the design turns out to be better.
I am not sure on the landscape in 1993 when it comes to coding but I suspect there was more of a design then code approach to building software. This chapter attacks this. Fast forward to now (2020) and I think there is a lot more acceptance for this.
Agile methodologies, as the dominant approach to writing code, may not exactly promote this but it certainly has evolutionary design traits. The building what you need and only adding to it when required fits the bill. Unit tests help enable this approach but also add a weight to refactoring that may not quite fit with the ideas that are going to be pushed in this book? Perhaps something more a kin to what I call functional tests would be a better balance. That way “unit” can change frequently without having to update many tests.
This is just conjecture on my part. I am certainly interested to see where this books goes and how it reflects with today’s practices.
A nice quote from the chapter is: In Lisp you don’t just write the program down to the language you build the language up towards the program.
Finally there is an admission that Lisp is more suited to small teams rather than very large ones. He argues that Lisp can be used to maximise the productivity of small teams so they can take on and beat larger teams. As part of my reason for wanting to learn lisp to increase my own personal productivity it is music to my ears. Go team of one!