This article misses the most important rule of framework building: don't build a framework to solve a class of problems until you've seen at least three concret

This article misses the most important rule of framework building: don't build a framework to solve a class of problems until you've seen at least three concrete instances of the class. If you don't respect that guideline you'll provide abstractions for the wrong design elements. Unnecessary indirection will be introduced to factor things that don't vary from instance to instance, and things that do vary will be missed. It's a difficult lesson to learn for the abstraction astronauts who want to throw a bunch of the most powerful language features at any problem...