I came across this one hour lecture [1] on Youtube. It's from 1994, but I think it's still very relevant today, both to developers in general and to the D language in particular.

A TL;DR summary of the lecture:
Abstraction is a central theme in software engineering, since it allows us to control complexity. However, most abstractions in software development do not (and cannot) completely hide their implementation; the implementation leaks via the performance characteristics of the abstraction. This is because the designer of the abstraction chose to implement its interface in some specific way, making design decisions that may be different than those that some clients would have wanted. The lecturer then suggests the following remedy: In addition to providing the client with a suitable interface, we should also allow him to make changes to the implementation through a separate "meta interface", i.e. we should allow him to change some (or all) of our design decisions. The lecturer suggests making such a meta interface using reflection and OO techniques but doesn't go deep into that.

This reminds me a lot of D's Design by Introspection, and also of a previous paradigm that Andrei introduced to C++ (Policy Based Design [2]). C++ and Rust throw the phrase "zero cost abstractions" around but without good compile-time introspection support, you can't really get there - as soon as you make a non-trivial design decision you've limited the user of the abstraction in some way. For instance, the interfaces of Rust's HashMap [3] and C++'s unordered_map [4] do not allow for a custom collision handling policy. The Rust implementation uses Round Robin hashing while for C++ it isn't specified (as far as I can see). That said, Phobos doesn't have a hash table implementation at all so maybe this isn't the best example :=) Still, I think that D looks much better than them as far as "zero cost abstractions" go.

[1] https://www.youtube.com/watch?v=5l2wMgm7ZOk
[2] https://en.wikipedia.org/wiki/Policy-based_design
[3] https://doc.rust-lang.org/std/collections/struct.HashMap.html
[4] http://www.cplusplus.com/reference/unordered_map/unordered_map/

Reply via email to