Search code examples
smalltalklate-bindingearly-binding

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


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.


Solution

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