late binding references

WHAT IS LATE BINDING?

static, dynamic and late defined (Ron Teitelbaum)

If you wanted to animate a sequence you would draw your background, then design your cells, draw them up, color them and then film them in order.

This would be an example of static binding. Everything is designed and created before filing starts.

If you had a sequence where while the film was running everything was changeable that would be dynamic binding. The system running the sequence doesn't need to know before it runs what it is going to do.

Squeak uses extreme late binding and you can see that because the program is actually running while you use it. You are using squeak to program squeak. This is much different then the programs where you write code, compile it (which does the binding and checks for errors), and then run the code.

Matching socks analogy (Mark Pilgrim)

Late binding is throwing all your socks into the one drawer. Early binding is matching them beforehand.

"I have a perfectly good system. I take all the socks out of the dryer and throw them into my sock drawer."

walnut analogy (Ian Piumarta)

In conventional programming languages, the programmer has control over how to write the source code and what behavior to obtain, but all other things (syntax and semantics of the programming language, compiler, run-time; and on a lower level, system libraries, OS, hardware) are rigid and imposed from the outside. The typical programming languages are disastrously early-bound, provide insufficient meta-data, no reification of implementation, and they artificially hide the internals: they're like walnuts, hermetically sealed and taking big time (just like for a squirrel) to get at the juicy stuff that's on the inside of the shell.

WHAT IS LATE BINDING GOOD FOR?

Software: Art, Engineering, Mathematics, or Science? (Alan Kay)
Problem:
Software engineering is complicated. It is not yet as scientific as engineering. It took many years to progress from building the pyramids to building the Empire State Building.

Solution:
I think this is what needs to be done to finally create software engineering. We need to do more building of important software structures, and we need to do it in a form that allows analysis, learning, and reformulating the design and fabrication from what has just been learned.

There seems to be a bit of a chicken and egg problem here. If we don't really have an engineering discipline, then won't it be too difficult to make big constructions that are also understandable enough to learn from? And won't the mess we've made be too difficult to reformulate to give us a chance to understand whether our new findings really have value?

I believe that the secret weapon that can be used to make progress here is extreme late binding. Of what? Of as many things in our development system as possible.

One can make a good argument that most of the advances in both hardware and software design have been facilitated by introducing new latebinding mechanisms. Going way back in hardware, we can think of index and relocation registers, memory management units, etc. In software, we went from absolute instruction locations and formats, to symbolic assemblers, to subroutines, to relocatable code, to hardware independent data structure formats, to garbage collection, to the many late binding advantages of objects, including classes and instances, message sending, encapsulation, polymorphism, and metaprogramming.


design is hard (Alan Kay)
The biggest problem in programming is not so much the strange seeming nature of the raw materials, but that as things scale up, architecture dominates the materials. I.e. design starts to become more and more of a factor. And design is not learned in a day, even with the best materials and environment. The very best programmers and computer scientists I know -- who have absolutely no problems with raw materials -- still have great difficulties with design for most systems that are worth doing. This is one of the reasons we like to make things late-bound: we don't know what we are doing half the time, and are constantly finding out things that we needed to know earlier....

In the case of designing computer stuff, there really isn't enough of a body of great design yet to provide thousands of applicable patterns, and so even seasoned professionals tend to flounder. And, again, better late-binding of everything extreme late-binding) really helps us flounder our way towards some of our goals

Why is Croquet built on Squeak?

Croquet required a number of capabilities that could only be provided by a true late bound, message sending language. Croquet's relationship to Squeak gives Croquet the property of a purely object-oriented system. This allows for significant flexibility in the design and the nature of the protocols and architectures that have been developed for Croquet. An essential part of our development process is Squeak's ability to keep the system running while testing and especially while making changes. Squeak allows even major changes to be performed incrementally and they take no more than a fraction of a second to effect. Another key feature of Squeak is its generalized storage allocator and garbage collector that is not only efficient in real-time (so that animations and dynamic media of many kinds can be played while the garbage collector is collecting), but that allows reshaping of objects to be done safely. It may be interesting to note that when we first set out to build Croquet, we intended to do it in Java. However, we had to abandon that approach because Java lacks needed meta facilities.