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.

Ley

Something to think about is that a lot of languages offer both including VB, Objective-C, C++/COM, and C#. – Singspiel

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.

Sporocyst

Then do you expect that we will increasingly be turning to late binding languages? Or that existing languages will morph from early to late? Are late-binding java and C# reasonable concepts? – Ley

@[le dorfier]: hardware keeps getting faster, so the overhead becomes less significant – Ramulose

I know. But is that the only reason all languages are not late-binding? Smalltalk was nearly acceptably fast 20 years ago - it should be way fast now, but it's not dominant. In particular, we're still saddled with early-bound C# and java as languages of choice for most new non-web apps. – Ley

And a JITter will allow some method calls/message sends to turn into (nearly) early bound calls. – Chandos

Answer 2

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.

Inlay

I contend that early-bound languages are actually harder to develop for. While they do gain advantages from tools using compile-time info, they also suffer losses such as verbosity and redundancy, and substantial language complications to accommodate occasional dynamic typing while still conforming to the constraints of the type system. E.g. generics are a great language feature, but are also a substantial complication. Dynamic languages don't need such a feature because everything is generic, all the time, whether the original author intended it or not, without requiring any extra syntax. – Repellent

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.

Previdi

Answer 4

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.

Occidentalize

Late binding is also simply possible by lower-level languages. This is because you only have to fill in a jump-table via hash-lookup once you bind lately. After that you can simply call the lately-bound functions via the jump-table, which is low-cost. So only the one-time late bind process needs time. – Saltatory

Answer 5

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...

Idiopathy

Answer 6

compile time binding in which linking is performed during the time of compilation is known as early binding

dynamic binding in which linking of function performed during the execution when function is called is known as late binding

Kano

It's more complicated than that. DLLs don't get linked in til runtime, but in most cases (GetProcAddress or dlsym aside), that's still considered early binding. – Noblenobleman