> Math can usefully be described as a nothing but a bunch of design patterns, discovered and built in just the way you say. Well, kinda-sorta. It depends on ho

> Math can usefully be described as a nothing but a bunch of design patterns, discovered and built in just the way you say. Well, kinda-sorta. It depends on how you define a design pattern, and how you generalize that definition to mathematics. The way that I define design patterns, I would disagree. I define design patterns as "an abstracted, re-usable piece of functionality that cannot be made into a library." I think that the non-libraribility is the defining feature of design patterns: it's why you have to learn to implement them, instead of just linking to them like most other forms of re-usable functionality[1]. As soon as you can figure out how to factor that functionality into a library (or template or inheritable class or interface or whatever), it's no longer a design pattern. When I look at mathematics, I would consider that to be mostly a collection of libraries rather than design patterns. Theorems, obviously, are more like libraries because you can simply plug in the antecedents and get out the sequents without looking at the proof. There are also things like design patterns, techniques that you can apply in related domains. However, mathematicians have a pathological urge to turn these techniques into theorems by proving properties about what they will do and when they can be applied. The result is that math tends to have many libraries but few surviving design patterns at any point. [1] Note that this definition is language-dependent. It also dovetails somewhat with the "design patterns are evidence of an underpowered language" line of thought, but is distinct because it deals with extensible functionality rather than built-in functionality.