“Late-binding” is an idea about having desired functionality while retaining as much flexibility and safety as possible.

A big one to consider is that “software” itself is a late-binding of how a computer will behave. (Seems to be a pretty good idea, I’d say …)

At the next level, the idea of index registers in hardware late-binds addresses in a way that is not destructive of code. Memory management units (MMUs) allow global relocations with encapsulated local addressing. Indirections of various kinds allow easier changes at run-time.

Consider a variable …

Consider a subroutine compared to in-line code …

An interpreter late-binds semantics of a computer.

Consider microcode as a way to later bind the hardware via an interpreter

An encapsulated object late-binds the “hows” (methods) and allows usage just via “whats” (meanings), and this allows various kinds of alternatives and transparencies to be more easily accomplished.

The “hows” themselves can also be late-bound e.g in Lisp or Smalltalk this allows programs to analyze how other parts of the system are set up: to “reflect” on what and how things are done.

(“Reflection” done well, and allow more pragmatic possibilities, even at a very low level, to be carried out safely and efficiently. A good book — mentioned in a comment below — is “The Art of the Meta-Object Protocol” by Kiscales, Bobrow, Rivera …)

From a strategic standpoint, retaining as much late-binding as possible is a very good idea. It is much easier to dynamically remove some of the degrees of freedom if absolutely needed, but really difficult to go the other way round from an early-bound system to more flexibility.

For example, quite a bit of optimization is violating module boundaries and hoping to get away with it. One way to do this in a more principled manner is to really have late bound modules as a model, and then implement the violations as “pragmatic features” of the programming system.

For example, a method in an OOP system could have a “left-hand side” that is just semantics, and an optional “right hand side” of cases with optimizations. The method should run perfectly with the right hand side turned off, but will run faster etc with it turned on.

Similarly, interactions between modules can also be handled in this dual way. (For example, Smalltalk is a “message passing system” but did not manifest actual messages unless absolutely required. Also, Smalltalk had simulations of all of its semantics and could retreat to them if the lower levels on some machines were not complete or had bugs.

It’s worth noting that deep enemies of graceful and useful late-bindings are pernicious — and especially gratuitous — dependencies. These can happen in an early bound system, but there are more possibilities in a late-bound one (so much more design is required to really take advantage of the idea — this will pay off in many ways …).