Here's another msg from Alan Kay that may be of interest to others as well. A good explanation of late binding - powerful especially for working out ideas:
> Here's how I think of "extreme late-binding". > > Suppose you are working on something and at some point you realize > that you'd like to change it or some part of it. If you can do that > pretty easily, then that change would be called "late-binding". If you > can't do it easily, then whatever it was would be called > "early-bound". Some materials are erasable and some not. Some forms > of images are more erasable and changeable on a computer than on > standard physical media, etc.: they are more "late-bound". > > For example, many operating systems and applications will require you > to reboot your machine after certain kinds of updates. (I just got a > new MacBook and was surprised that after it updated its apps from the > net that it required a reboot -- this would be more expected on > Windows than on a Mac.) These updates were "early-bound" and something > major had to be done to rebind things. > > Lots of programming and apps 40 years ago were early bound (one had to > go back to source text, recompile, reload, rerun, etc.). Interactive > systems started to try to late-bind as much as possible, so that a > change by a user would be immediately reflected. Compare the > late-bound changing of a picture in a graphics app or some text in a > word processor or a Hypercard script to the much more tedious > task of using a blog or wiki which requires the text to be typed one > way, and only later do you see how it turned out. That this situation > obtains today in the web is terrible (most especially since there is > no good reason for this, just really bad design by the people who did > the web browsers). > > Lisp was one of the first programming languages to experiment with > late-binding much more than had previously been done. And we took this > up as one of our goals at Xerox PARC in the 70s: to see how much you > could allow to be changed on the fly without killing the entire > system. The Smalltalks went rather far in this direction (and could go > further). (Squeak is a Smalltalk.) > > For kids, we wanted them to have instant feedback on everything they > did, so we took the Hypercard model and tried to remove its various > modes, enrich the graphical landscape, and simplify the programming. > We aimed at 8-12 year olds, and Etoys works pretty well for them. > > Etoys was a demo that was supposed to be reimplemented as a wider > ranging system for children from about age 5 into high school. But > this didn't happen, and the result is that Etoys remains mostly useful > for the original age group. For example, it would be pretty > frustrating for you to try your project in Etoys. > > Squeak on the other hand is a full blown programming environment (like > Java) and your project could definitely be done in it). But it is much > less suited to the kind of user you say you are. (I think you sell > yourself short a bit because anyone with a good command of writing > skills -- and you certainly have these -- can learn to program in the > general non-iconic forms used today.) > > 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. > > One analogy (that might be unsatisfying) is that many people have > complained about the ad hoc nature of standard musical notation and of > the layout of the piano keyboard (which leads to lots of scale > patterns, etc.). And, it's true they are a pain when starting, and do > turn lots of beginners away. Many suggestions have been made to > improve both of these. > > Once one gets into the stuff, one realizes right away that real > fluency doesn't depend much on the actual notation or keyboard layout. > This is because fluency in the human brain is done by flattening > structures into thousands of special cases. There are real > similarities here to reading and spelling. It helps to have phonetic > spellings in the beginning, but they are completely bypassed by fluent > readers. > > 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. > > Cheers, > > Alan
