Building Abstractions with Data
Notes on the second chapter
Quotesλ
The book answers its own question, Why do we want compound data in a programming language? With an answer I quite like: “to elevate the conceptual level at which we can design our programs”Thought this was funny:
“Thus, we could design a program in which each rational number would be represented by two integers (a numerator and a denominator) and where add-rat would be implemented by two procedures (one producing the numerator of the sum and one producing the denominator). But this would be awkward, because we would then need to explicitly keep track of which numerators corresponded to which denominators. In a system intended to perform many operations on many rational numbers, such bookkeeping details would clutter the programs substantially, to say nothing of what they would do to our minds.”
Revelation from abstraction barriersλ
In one section they talk about the design of their rational number package, and how the barriers of abstraction allow the implementation details to change without affecting the API.I’ve known this already, but re-reading it made me realize of a way I could save engineering time. I sometimes find myself wasting time debating about engineering choices, should I do x or y? But if the change doesn’t permeate the abstraction barrier, meaning the API will stay the same, then the surface area of change from making decision x or y is very small, meaning I should spend little time picking one or the other since it won’t majorly affect the code, and thus I can always go back and change it with very little ramifications to suffer.
So in my checklist of questions to ask when making a decision I should ask, “Does this permeate the abstraction barrier?”
Found CEO of replitλ
While looking at an exercise solution, I found @amasad. This was particularly funny because I am reading the book with @itsarnavb, who works at replit!1983 was a long time ago…λ
The first sentence of an exercise, “A binary mobile consists of two branches, a left branch and a right branch”. Well apparently it’s a dream-catcher or wind chime like figure… Perhaps in 1983 this would have been more clear, but in the 21st century one immediately jumps to the idea of mobile phones.Exercise 2.6 - Church numeralsλ
Boy is that a funky way to represent numbers. Still curious about the practicality of this, but satisfied I got an introduction to lambda calculus.Seinfeld effect, and what other hidden gems does FP have to offer?λ
Finally getting into some comfortable territory as the book introduces “signal flow”, which is basically the scheme version of those map, filter, reduce array functions I’m used to. I get the sense that this section is supposed to be revelatory, but I’m experiencing a bit of the Seinfeld effect, since I have seen this heavily in JS/TS and Rust. Nonetheless, I am having a great time coding like this which greatly enhances the conceptual clarity of my code.This is one of FP’s most successful influences into imperative land, and I wonder what other hidden gems FP has to offer to the mainstream.