NaN

How about “all the things that are true and none of the things that aren’t true?” (Not sure how well the latter part would go over.)

I loved my course on patterns. It was tough, but I now regularly feel like I can apply mastery of this tricky subject to my software projects. The course used a variety of techniques:

• Read the seminal Design Patterns book by Gamma et al., for an overview of the concepts.
• Every week, we'd incorporate three patterns into a preexisting XML processor project. My final one had like 25 patterns, which was challenging to keep working amidst refactoring. (You don't have to do them cumulatively, but I enjoyed it.)
• We'd have to ask pattern-specific questions of our classmates in forum threads; and occasionally we'd be assigned to answer some.
• We each wrote up our own pattern. (I designed one based on my experiences handling data exchange between web apps and clients.)

Together, this taught us

• How the patterns could concretely look in practice.
• Pros, cons, and other considerations for each.
• Similaraties, differences, and nuances. (We'd joke that everything was the Template pattern if you squinted.)
• The impact of modifications to the patterns.
• How to recognize, create, hone, collaborate on, and share patterns.

I appreciate this approach because patterns are an inherently fuzzy subject.

It's more like languages evolved to incorporate the most common idioms and patterns of their ancestors. ASM abstracted common binary sequences. C abstracted common ASM control structures and call stacks. Java leaned hard on object orientation to enable compositional and inheritence-based patterns widely used in C and early OO languages. Python baselines a lot of those patterns, and makes things like the Null Object pattern unnecessary.

Can we call communities “lemlets?”