But there’s another way of thinking about dynamic types: a dynamically typed language is one where types are runtime values and manipulable like all other values. It’s a short hop from there to thinking of the whole runtime environment in the same way, where everything is a runtime construct.
He then gives a number of applications. I would summarize these applications as being things developers might want to know about their program as it runs, enabling future changes to the code or validating past changes. For instance, checking that an optimized function produces the same result as an unoptimized function. Or providing better information about failed test executions.
To me, this feels very much like aspect-oriented programming, where one could provide advice modifying the execution of Java programs. One would typically state some program points where the advice would apply (“method foo()”) and perhaps a predicate. If true, then the program would execute some provided code.
No one really talks about AOP these days. The aspectj compiler produced some quite slow code, and there were efforts like the abc AspectBench compiler to make it produce faster code. But I think the real problem was that, at the time, no one could really come up with applications besides debugging and tracing. I don’t think you’d want to deploy aspect-oriented code which had functional effects into production! It’s too hard to reason about!
Maybe the right thing would have been as a tool for program introspection and augmenting the usefulness of test suites. It’s quite hard to evaluate such a tool, but that doesn’t stop us usually. Certainly there was no killer app for AOP; and test suites, which come up in Hillel Wayne’s examples, weren’t thought about as much.
(I was recently on Blad Glasbergen’s PhD committee; he invented a system for tuning database engines at runtime. That could also have benefited from aspect-oriented programming, I think, though really to change nonfunctional properties of the database engine.)