2006-05-30 #1

Late-Binding == High-Level ?

says

I've been thinking lately that the most significant difference between what I consider high level and low level languages is that high level languages do lookups via associative arrays and low level languages do lookups via arrays (often pointer offsets determined at compile time). Basically, whether or not they are based on dynamic binding. In this sense, languages like Lisp, Haskel, C++, C# and probably most of Java would be considered low level.

This reminded me of a some of the work done with Meta-Object Protocols (MOP's) at XEROX, where they actually let you control the instance memory allocation scheme through the MOP. No approach is ideal in all situations but by bringing the implementation under developer control you have the option of choosing the strategy which suits your needs best. This can be done on a class-by-class basis rather than globally. You could imagine how this would make implementing on object database very simple.

This also reminded me about some of the things that Alan Kay has said about late binding:

One way to think about progress in software is that a lot of it has been about finding ways to late-bind, then waging campaigns to convince manufacturers to build the ideas into hardware. Early hardware had wired programs and parameters; random access memory was a scheme to late-bind them. Looping and indexing used to be done by address modification in storiage; index registers were a way to late-bind. Over the years software designers have found ways to late-bind the locations of computations--this led to base/bounds registers, segment relocation, page MMUs, migratory processes, and so forth. Time-sharing was held back for years because it was "inefficient"-- but the manufacturers wouldn't put MMUs on the machines, universities had to do it themselves! Recursion late-binds parameters to procedures, but it took years to get even rudimentary stack mechanisms into CPUs. Most machines still have no support for dynamic allocation and garbage collection and so forth. In short, most hardware designs today are just re-optimizations of moribund architectures.

I see the current Inversion of Control (IoC) movement with Java as a way to add late-binding to the global namespace (or more correctly, as a late-binding replacement for the early-bound global namespace).