EarlyBinding

ThoughtStorms Wiki

In contrast with LateBinding

Quora Answer : Is the pervasiveness of early bound programming languages and architectures throughout computing history partly caused by most people not working on hard enough problems to be forced to consider late binding as something crucial?

Mar 6, 2018

Initially it's that early-binding means that more work is done at compile-time and less at run-time, so people choose early-binding to get speed / efficiency.

When computers used to be fairly slow and low-powered, people cared more about that.

So people would write their code in C because "C is more efficient". In other words C binds function names to memory addresses at compile time and doesn't waste any time during execution asking "so when you say f(x) which f are we actually talking about?"

Today, people don't worry about that much. But all our mainstream OS's are still written with a C mentality.

There are two families of systems that are written the way Alan Kay suggests : Smalltalk, obviously. And Erlang, which is extremely focused on the virtues of hot-swapping / recompiling bits of a working system. Even allowing half the system to crash due to failures and then having supervisors automatically restart.

The downside is that both of these are fairly closed, opinionated, worlds. You have extra infrastructure in the system to support the late-binding. So that means that early bound programs aren't really welcome. (Or are, at best, emulated on top of them so all their "virtue" is lost).

OTOH, an OS designed for C ... you can run a Smalltalk image or Erlang OTP or even Java VM on top of them, and have what you want from those worlds. But you can do the other thing too.

So, at the lowest level, simple, early-bound, is basically more "flexible". It supports "polyglot" world of different styles of programming and different thinking in different languages.

The beauty of Smalltalk (and Erlang) is the tight integration between language and environment / platform. The language knows about the platform. Its semantics are designed to give you expressive power over the platform's deep virtues. At the same time, this is also their great weakness. They only make sense on their platform, and that platform only really makes sense when programmed with those languages.

Linux, OTOH, is a general purpose container that can be adapted to any style you like.

Now, in practice, people are always building things on top of Linux and the internet, which look very like these languages.

In fact it's kind of hilarious.

On the one hand Docker / Kubernets's style containerization is reinventing what the Smalltalk image gave us 40 years ago. A reliable, portable, shippable, self-contained world.

On the other, Amazon's "Lambda" and the whole idea of light-weight, "serverless" (ie. stateless) function-as-a-service. Are just reinventions of the Erlang platform.

In this sense, the ideas that Kay is talking about are very relevant and increasingly important. Exactly because we're trying to make large, long-lived, easily accessible and modifiable systems.

The question is, how do the specific platforms that implemented these ideas originally, the original Smalltalk VM and Erlang OTP, adapt themselves to this new world.

No Backlinks