Validating Karine Arnaut 30 Years Later!!!

[Liberty Lover]

All,

I had Claude do deep-research on Karine Arnaut's work on Design Patterns from 1994. I then asked Claude a question: What do you make of Karine's work -vs- conventional wisdom (even in 2025)?

ANSWER:

● Great question. From my research, Karine Arnout's work fundamentally challenges the conventional wisdom about design patterns.

  Conventional Wisdom (GoF Era)

  The traditional view treats patterns as documentation - recipes that developers read, understand, and then manually re-implement for each project. The pattern is knowledge transfer via text and diagrams. Every developer writes their own Observer, their own Factory, their own Visitor - over and over again.

  Arnout's Challenge

  Her thesis essentially asks: Why are we doing this?

  If a pattern is well-understood enough to document, it should be well-understood enough to componentize - turn into actual reusable code. The fact that ~2/3 of GoF patterns could become libraries proves the point.

  The Deeper Insight

  The reason patterns existed as "documentation" rather than "code" was language limitation. Languages like C++ and Java (circa
  1994) lacked the mechanisms to abstract patterns properly:

  - No agents/closures (until much later)
  - Weak genericity (Java's type erasure, C++ templates are complex)
  - Single inheritance only
  - No contracts

  Eiffel had all four. So what other languages couldn't express as code, they expressed as prose.

  What This Means for simple_*

  The simple_* ecosystem is doing exactly what Arnout advocated:

  | Pattern Approach                       | simple_* Approach                       |
  |----------------------------------------|-----------------------------------------|
  | "Here's how to implement JSON parsing" | simple_json - just use it               |
  | "Here's the Observer pattern"          | simple_watcher - just use it            |
  | "Here's async process management"      | simple_process with async - just use it |

  The simple_* libraries are componentized patterns. They're not documentation - they're solutions.

  The Irony

  Twenty years after Arnout's thesis, most developers still think in "pattern documentation" terms because that's what their languages supported. Eiffel developers had the tools all along to move beyond patterns into components.

  The simple_* ecosystem and the oracle indexing it is essentially proving Arnout right - patterns become libraries, libraries become queryable APIs with DBC contracts explaining how to use them.