Programming builds abstractions on top of abstractions: we use (“consume”) some layers in a stack of abstraction, and often build (“produce”) new layers towards the system behavior we desire. While most “knowledge work” relies on abstractions (when the work can be characterized as “communication”, building abstractions is also common), this talk focuses on programming, where such issues are burningly important, technical, and real, on a day-to-day basis.
Like leverage in financial operations, abstractions are precious, indeed indispensable, in programming. You can’t build a useful program focusing on how your code makes computer transistors switch back and forth… and if you COULD usefully think in such lower-layer terms, you’d still be using layers of abstractions, by thinking of transistors rather than quanta and quarks;-) Just like leverage, abstractions can be dangerous in proportion to their power, liable to make the whole system “explode in your face” unless handled with prudence and awareness… and that’s what this talk is all about.
Joel Spolsky’s “Law of Leaky Abstractions” focuses on one cause of danger: “All non-trivial abstractions, to some degree, are leaky”. Implementation aspects inevitably “show through” at the most inopportune moments… bugs, anomalies, system overloads, security attacks. You need awareness of a few layers that are lower on the stack than the level you’re working at (i.e., awareness of the “implementation details” that every pundit tells you to ignore!-) to architect your software for efficiency, robustness against security attacks, ability to debug when the need arises. The temptation to ignore all layers below your chosen one must be resisted.
But wait, there’s more! Abstractions, often, should leak… in a designed, deliberate fashion. The best way to customize a stack of abstractions will often be to layer yet more on top… but, not always: sometimes, “hooking up” extra or modified functionality at lower layers offers more powerful AND safer leverage than building a too-thick superstructure. Keep this in mind when you produce abstractions: are you offering appropriate “hook points” to let an advanced consumer of your abstractions tweak and customize them towards their goals, which you cannot fully anticipate?
As an abstraction consumer, look for the hooks (don’t be surprised if they’re poorly documented…!) and consider their appropriate uses. Breaching the “architectural wall” between layers (making the abstraction leak by force, when it wasn’t designed to), e.g. by the alas-too-popular technique of “monkey-patching”, is a desperate measure that should only be used, if ever, to wiggle out of the very direst straits: if you’re using an abstraction stack that just won’t let you get your job done without going to such extremes, you’re probably better off switching to a completely different one!-)
Alex Martelli wrote “Python in a Nutshell” and co-edited “Python Cookbook”. He’s a PSF member, and won the 2002 Activators’ Choice Award and the 2006 Frank Willison Award for contributions to the Python community. He works as Senior Staff Engineer for Google. You can read some PDFs and watch some videos of his past presentations.
Comments on this page are now closed.
For information on exhibition and sponsorship opportunities at the conference, contact Sharon Cordesse at firstname.lastname@example.org
Download the OSCON Sponsor/Exhibitor Prospectus
For media-related inquiries, contact Maureen Jennings at email@example.com
To stay abreast of conference news and to receive email notification when registration opens, please sign up for the OSCON newsletter (login required)
View a complete list of OSCON contacts