And GOF-style design patterns -- which are heavily implementation-recipe-centered -- aren't the same thing as design patterns more generally.

> The pattern describes the /concept/ and allows the builders to call an arc "an arc" instead of describing the tedious 100 steps required to actually build one and the explanation of why it works.

GOF-style design patterns actually describe the tedious 100 steps required to actually build them, and are in particular selected not by their general applicability but by the fact that they are specifically things that cannot be abstracted in the languages of the time that the book drew from, e.g., they are largely implementation recipes for things for which implementation recipes rather than reusable libraries are required in the common OO languages of the time the book was assembled.

> I can implement 200 singletons and have no need to re-use them.

Yes, but the reusability I'm talking about isn't the individual implementation but the common infrastructure -- with a language that is more flexible than, you can build the infrastructure for a singleton once, and the next time you don't have to build a whole singleton implementation, just the bits that are unique. With physical architecture, you have to build the whole thing each time, so implementation recipes are, to an extent, an unavoidable accompaniment to design patterns, rather than a sign of a problem with the implementation medium (in the case of programming, the particular language.)