Over the years, a few programming paradigms have been successful enough to enter the casual vocabulary of software engineers: procedural, imperative, object-oriented, functional, generic, declarative. There's a B-list, too, that includes paradigms such as logic, constraint-oriented, and symbolic.
The point is, there aren't very many of them altogether. Easy to imagine, then, the immensely humbling pressure one must feel when stumbling upon a way to think about writing code that is at the same time explosively productive and firmly removed from any of the paradigms considered canon.
This talk shares early experience with Design by Introspection, a proposed programming paradigm that has enough demonstrable results to be worth sharing. The tenets of Design by Introspection are:
The rule of optionality: Component primitives are almost entirely opt-in. A given component is required to implement only a modicum of primitives, and all others are optional. The component is free to implement any subset of the optional primitives.
The rule of introspection: A component user employs introspection on the component to implement its own functionality using the primitives offered by the component.
The rule of elastic composition: a component obtained by composing several other components offers capabilities in proportion with the capabilities offered by its individual components.
These rules, and how to use them to build powerful software, are the topic of this talk.