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

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.

Answer 2

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 3

Late-binging allows the running system to extend itself. For example, system starts up knowing about Wolves. As time passes an evolveDomesticate() method, in Wolf(?), spins a new class called Dog and instantiates that and we have Dogs now. Smalltalk would save the whole SYSTEM image so if you shut it down and restarted, Dogs would still exist after restart. Once you evolve to objects running on particular hardware and connected in a mesh network there is no real shutdown of the whole ecosystem (not until Sun blows up). I think this is what Alan Kay was talking of the advantage of late-binding, become a God.