Great talk! I think what's neat about the resulting code from thinking about the design of programs around their data is that you, with some careful API design

Great talk! I think what's neat about the resulting code from thinking about the design of programs around their data is that you, with some careful API design on top, can end up with faster code but also nice APIs... the implementation underneath is messy and harder to read, generally, but a good API fixes that so you don't have to think about it too often. The bit about "heuristics," is neat too. There are a lot of "theoretical computer science things," you can implement using the observations of what your program is actually doing to write a specialized version of that "theoretical computer science thing," that fits your program. A concrete example: push-based constraint solvers. To create a solver for the general case is all fine and nice... ... but 1. It will probably have poor memory performance for your program 2. It will be hard to use for your program since it has to be general: you may need to provide extra configuration or functions to it to handle your data. But you can write your own in a weekend if you build it around your specific use case and implement the solver around your data. It doesn't work for everything (ie: probably best not to write your own crypto) but it's a trade-off worth considering before pulling in another dependency.