Guy Steele on designing a programming language for library building (OOPSLA ’98 keynote)

Classic, and timeless. (HT: Patricia Aas, Tony Van Eerd and Peter Sommerlad)

Note that when he says “growing a language” he doesn’t mean literally the language itself — it’s not a talk about language evolution. Rather, he’s talking about enabling users to write rich and powerful abstractions in that language without having to go beg their language designer and compiler vendor to build them into the compiler every time.

Steele’s argument in the back half of the talk is on point, on the importance of imbuing a programming language with a few well-chosen “patterns” that allow, and guide, specific kinds of extensibility. His argument is a great description of why I’m pursuing metaclasses for C++, because we should have a convenient way for programmers to write their own Words of Power like “value_type” or “interface” as libraries instead of forcing them to go bother their local compiler writer (or local standards committee) for a language extension each time for that sort of thing. And his “as a pattern” description is a great summary of why I’m proposing them as “just” a sugar to apply a compile-time function in a very specific place and in a very constrained way, and not going anywhere near making a mutable language which would be crazy not worth pursuing.

One thought on “Guy Steele on designing a programming language for library building (OOPSLA ’98 keynote)

  1. Trust the programmer! Remembering that principle extinguished the concerns I had. The best feature of metaclasses is that programmers decide how they are used or abused. I would prefer them over any multifurcation of the type system. As a warning example, in C# the meaning of assignment operator depends on the keyword with which type was declared! The poor programmer has to keep in his finite head those keywords in addition to all else!

    But I think lightweight exceptions are more urgently needed. I don’t believe that dynamic exceptions will disappear, but C-style error handling will be finally obsolete, and division into incompatible dialects will stop.

In comments, use [code] [/code] for code blocks, and the same with angle brackets for code inside text paragraphs. I appreciate and try to acknowledge feedback on GotW articles; if you're suggesting an improvement for a GotW Solution post, please post under your real name (or include it in the comment text) if you would like to be acknowledged here and when the material is updated and expanded in future Exceptional C++ books.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s