[andralex]

Speaker here. Slides at https://erdani.com/dconf2017-slides.pdf. Ask me anything!

Abstract: 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.

[keldaris]

Excellent talk, it really makes one envious of the compile time facilities offered by D.

Do you see any other languages out there being amenable to at least ideologically similar techniques, or do you think this design paradigm will remain unique to D for the immediate future? In particular, I think some of the modern JIT-compiled languages, which often feature extensive reflection and runtime introspection capabilities, could theoretically be used in a similar way, as long as the compilation overhead incurred on the first run remains reasonably small. What are your thoughts on this?