[linux-audio-user] Re: Squeak (was Software suitable for children)

[Brad Fuller]

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