Early binding vs. late binding: what are the comparative benefits and disadvantages?

Question

When discussing the evolution of computer languages, Alan Kay says that the single most important attribute of his Smalltalk is late binding; it gives the language its malleability and extensibility, and allows inappropriate coupling to be refactored out over time. Do you agree? Are there compensating advantages for early binding that explain why it seems to be the dominant of the two paradigms for domains where either could be used?

My personal experience (which is not broad or deep enough to be authoritative), based on implement web applications with javascript, jQuery, jsext, actionscript, php, java, RoR and asp.net seems to suggest a positive correlation between late binding and bloat reduction. Early binding I'm sure helps detect and prevent some typesafety errors, but so do autocompletion and a good IDE, and good programming practices in general. So I tend to catch myself rooting for the late binding side, before my risk-avoidance side restores my rational perspective.

But I really don't have a good sense for how to balance the tradeoffs.

Answer 1

Traditionally the big advantage of early binding is for performance: a late binding language has to carry type information about all its data at runtime, and loses the opportunity to do some optimizations at compile time. This difference has become much less significant, though, as computers get faster, and as VMs get smarter about optimizing on the fly.

Answer 2

I think there are better ways/patterns to avoid inappropriate coupling, like inversion of control, dependency injection, Factories, ...

But, I like the "easy to use" version independence of late binding
Just use

var excel = CreateObject("Excel.Application");

and Late binding will figure out, what kind of Excel.Application, and where to get it from...

Answer 3

Early binding vs. Late Binding is really a function of language architecture. Early binding means that code can be built where a machine instruction just jumps to an address and starts executing from there (possibly via a lookup table). Late binding requires a symbol and type reference to be looked up (usually a hash table lookup) for each access, which slows the language down.

While some VM-based languages such as Java are early bound native machine code can only really do early binding directly. To do late binding it has to do the same sort of hash lookup as a dynamic language interpreter would. The late binding then requires a chunk of code to be executed to get the address (this is how OLE automation works). It cannot be done directly by the CPU - the code has to be executed.

Note that the code doing the late binding will actually have its own early bound branch targets in the hash lookup function and so forth. So, from this perspective, early binding is necessary for any code that is to be directly executed by the CPU. Late binding must be done in software.

Early binding is also necessary for quite a wide variety of code optimisations.

Architectures such as C have a sweet spot in writing code close to the metal, as it were. Where you want to do this the early binding aspect is pretty much inherent to the architecture of the language. In a late bound language such as Python the late binding is also inherent. Some languages offer both, but the particular type used will be tied to the particular construct being executed.

Answer 4

In my experience of both high-performance software (e.g. games, number-crunching) and performance-neutral software (websites, most everything else), there's been one huge advantage of late binding: the malleability/maintainability/extensibility you've mentioned.

There've been two main benefits of early binding. The first:

• Runtime performance

is commonly accepted, but generally irrelevant because in most cases it's feasible to throw hardware at the problem, which is cheaper. There are, of course, exceptions (e.g. if you don't own the hardware you're running on).

The second benefit of early binding:

• Ease of development

seems to be underrated. In large projects where developers are working with other people's components, IDEs can read the early bindings and use them to inform the developer (with autocompletion, docs, etc). This is less practical with late-binding because the bindings are created at runtime. It is still possible with late-binding languages if the IDE can infer structure definitions from the code, but since the structure can always be changed at runtime, it's not so reliable.

Ease of development is a big deal. It minimizes expensive programmer time -- and the larger your development team, the more significant it becomes. You'd need to balance that against the flexibility you get with late-binding languages.