Hey all! I came across this book yesterday, and bought the full version after reading the sample; currently roughly halfway through the book.
It seems very interesting: ‘discover’ a library by starting with a couple of simple datatypes and relationships (‘laws’) between them by first finding more laws, then creating a naive (slow but trivially correct) implementation which is then used to parity-test the final optimized implementation.
One of purely functional programming’s greatest strengths is its powerful abstraction capabilities. We proudly exclaim that our functions are referentially transparent, and because of that, our bugs will always be shallow. And this is often true.
10x is often cited as the magic number beyond which technology is good enough to overcome network effects. I’m personally convinced that functional programming is 10x better than any other paradigm I’ve tried. But if functional programming is so good, why hasn’t it yet taken over the world?
This is a very serious question. If we’re right about this, why haven’t we won?
Algebra-Driven Design is my answer to this question. Functional programming hasn’t taken market share because we collectively don’t yet know how to write real applications with it. Abstraction is our language’s greatest strength, but all of our “best practices” evangelize writing the same procedural code and use the same techniques as we would anywhere else.
Instead of giving up, this book encourages us to take a heavy focus on designing leak-free abstractions, on understanding programs so well that the code and tests can be largely generated automatically, and on finding performance improvements not via intuition, but through algebraic manipulation of the program’s underlying equations. Functional programming affords us so many new possibilities for designing and testing better code, but this information is scattered and lost in ancient journals. I’d like to change that.
Looks neat Marten! I can’t believe you are half way through it already!! (I must be a really slow reader - it takes me forever to finish a book! )
That makes this book interesting for me - I’m very interested in the architecting of apps, particularly larger ones and those with performance in mind so always keen to hear how people architect their apps.
Please let us know what you think of it when you’ve finished it
Read the second half of it (It’s ~370 pages including appendices), and loved it!
In a nutshell, the idea behind Algebra-Driven Design is:
Programming should not be code-centric; computer programs should be (only) the result of thinking about problems.
So program source code itself is the wrong level of abstraction when thinking about solving most problems.
Instead:
Create a structured model of understanding. (An algebra, if you will).
Check your model using e.g. QuickSpec to find out if your reasoning is correct, and what other laws might hold true to further refine it.
The output of the previous step can be codified as a rigid set of properties which any implementation of your abstraction must adhere to to be correct.
Only now we create an actual implementation based on the properties we’ve found. At every step of the way we can see whether we are on the right track because we have this clear suite of property-testing-properties available. This also means that refactoring and optimizing can be done fearlessly by anyone in the future.
Whenever we find a flaw in our reasoning, we can backtrack to an earlier step and continue from there.
And this is cheap since we haven’t committed hours or days to writing an implementation before finding out that the underlying concepts were incomplete or broken.
I think this workflow is beautiful. The one thing I am not entirely sold on yet, is on how widely it can be applied:
The book itself already states that this design flow is more ‘library-centric’ than ‘application-centric’,
although it also states that a concrete application ought to only be a thin wrapper around a group of reusable libraries (which I agree with).
However, while the two examples chosen in the book: ‘Functional Geometry’ and ‘Scavenger Hunt’ work really well for this technique,
there might be some survivorship bias here (these two examples might be chosen exactly because they work well).
I’ll have to try to apply Alg-DD to the ideas of me and my coworkers to see where its limits truly are.
In any case, I very much enjoyed the book, and whole-heartedly recommend it to people who want to learn a new technique for structuring their code.
The book explains the concepts it covers very well.
It should be easy to pick up for people who have a little functional programming skills.
It should also be possible to learn from it for people who do not have these skills yet (the book has a great appendix in which all the features the book uses are explained from the ground up), but it will definitely be a bit more challenging.
I do not think the techinques in the book are hard to learn; I do think that some of this knowledge goes ‘against the grain’ of current conventional Computing Science education,
which means that you might need some ‘un-learning’ if you’ve only encountered e.g. OOP with OOP-centric software design patterns so far.
Thanks for such an in-depth review Marten! What do you think the prerequisites are before reading this book?
I have definitely been feeling suffocated like this of late. For instance when doing Rails projects I am always thinking in Rails, same in other areas. I suppose part of why I like to read as much as I can before using certain tech is to see what is possible and what paths you have to get there… and which detours you can take.
I still can’t believe you read a whole book in two days
Some background in functional programming will help a lot (and it is probably the reason I was able to read through the book so quickly) but as bare prerequisite high-school math (i. e. working with equations involving variables and solving simple proofs with them) should be enough :-).
)
