What follows is a collection of notes, opinions, and other random thoughts related to the book "From Mathematics to Generic Programming".
Quick (Re/Over)view
From what I can surmise, a core goal of this book is to show the deep connections between programming and Mathematics, and to highlight the mathematical abstractions inherent in regular programming tasks.
Think of it as combining computer science with abstract algebra and other mathematical concepts that lend themselves to discussions with code. Throughout the read we are exposed to code, proofs and given grounded historical perspectives via origin stories of the underlying math.
It's also important to understand how Alexander A. Stepanov views mathematics as a study of numbers and shapes.
I view the approach taken to explain the concepts as a mashup of a few other books I have read. Think of it as the combination of Skeven S. Skiena's "The Algorithm Design Manual", or Robert Sedgewick's "Algorithms" combined with Ian Stewart's "In Pursuit of the Unknown - 17 equations that changed the world".
Generic Programming
To make sure we are on the same page as the authors, they define "Generic Programming" as:
Generic Programming : Is an approach to programming that focuses on designing algorithms and data structures so that they work in the most general setting without loss of efficiency.
I agree that the usefulness of code improves greatly, perhaps even improving a code base non-linearly, when its made to work in the abstract. But I would caution pulling ourselves too far out from the concrete applications which the code serves.
In theory there is no difference between theory and practice. In practice there is. — Jan van de Snepscheut
To build our castles too high in the sky, without concern for user's priorities or perceptions would be a grave mistake indeed. So just remember that we yes, we should embrace well structured, general code bases but we must always align our code to best support real world applications.
If you have built castles in the air, your work need not be lost; that is where they should be. Now put the foundations under them. — Henry David Thoreau
A good way to avoid building beautifully abstract but completely worthless code is to constantly be using our abstractions in real world applications and test cases.
All this is not to say the authors don't understand this. In fact they explicitly make the same point:
To see how to make something more general, you need to start with something concrete. In particular, you need to understand the specifics of a particular domain to discover the right abstractions.
Sense of beauty is important for building large systems and controlling complexity
Study of mathematics helps to develop this sense. Why? Well, arguably programming to a large degree, involves mathematics, so then its only logical that if you understand beautiful mathematics then you could in theory strengthen your understanding of beautiful code. It doesn't mean that its the only way, of course not, but it could help.