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
Received on Tue Dec 12 00:16:00 2006
This archive was generated by hypermail 2.1.8 : Tue Dec 12 2006 - 00:16:00 EET