John Perry Barlow, Vint Cerf, Richard Dawkins, Doug Engelbart, Marvin Minsky, Nicholas Negroponte, Seymour Papert and so on. Did you know that you're making ridicule of a big chunk of the history of informatics?

Rob wrote: I totally agree with this. But still I respect them. Not the famous people, but great innovators. I couldn't care less for PhD's. I'm for self-education. Squeak, BTW, has been inspired by the construtivism theories and by softwares like Logo and HyperCard. Not really meant for PhD's.

Transcript show: 'Hello world'.

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