Interestingly, this work led Gregor Kiczales & team to create Aspect Oriented Programming - a subset of his metasystem - which became somewhat popular with Java and the Spring framework's use of AspectJ.
http://en.m.wikipedia.org/wiki/Aspect-oriented_programming
As an aside, I found in college (let along high school!) that students have almost anti-philosophical learning objectives. The SICP approach of teaching computer science from the metasystem up with Scheme (and then possibly moving on to CLOS/Lisp) was near-universally hated among my peers (1996-2002) - most wanted a practical language they could "get a job" with. I believe MIT first year CS switched to Python in part to deal with this resistance.
> I believe MIT first year CS switched to Python in part to deal with this resistance.
In part. The full story is a bit more depressing: http://www.wisdomandwonder.com/link/2110/why-mit-switched-fr...
Most of the other top universities that had used SICP also switched shortly after MIT.
This was me in college. Especially early on, I kept hounding my professors why they weren't teaching a particular language (e.g., C++) or toolchain (Visual Studio). It wasn't until well after I graduated that I appreciated the distinction between using tools and making tools---and that my professors taught me the latter.
One can change everything, and manipulate even the UI. Even the DevTools in all browsers nowadays are HTML5 iframes.
Manipulating the objects and meta/prototype objects are features that both languages allow.
Though they are different, and afaik only JS is called a prototype based programming language: http://en.wikipedia.org/wiki/Prototype-based_programming
Sure, they're "similar", but at a relatively low approximation. The capabilities of the Smalltalk environments are simply on a different plane.
Manipulating the objects and meta/prototype objects are features that both languages allow.
This is sort of a bare minimum for all OO languages. Even Java with its rigidity allows for complex tricks with reflection and method body replacements for hot code reloading.
While this is often considered to be one of JavaScript's weaknesses, the prototypal inheritance model is in fact more powerful than the class based model. It is, for example, fairly trivial to build a class based model on top of a prototypal model, while the other way around is a far more difficult task.
> The capabilities of the Smalltalk environments are simply on a different plane.
Please explain. Maybe use the following examples: FirefoxOS and Squeak
This is precisely what Kay is arguing against in his second point. In Smalltalk everything is an object including classes but there is a sharp distinction between a class and other objects and it's very important to make this distinction. It's important to be explicit about which level you are operating on.
In general arguments about one thing being better than another because you can express one in terms of another don't hold up. Then you can argue that assembly is the most powerful of all. (see also the definition of Turing Tar Pit)
not in languages where you can control method dispatch and object allocation (smalltalk, ruby, python etc), than it's quite trivial.
Some relevant excerpts:
Here are some examples of conventional operating system
components that have been naturally incorporated into
the Smalltalk language:
[...]
Display handling -- The display is simply an instance of
class Form, which is continually visible, and the
graphical manipulation messages defined in that class are
used to change the visible image.
[...]
Debugger -- The state of the Smalltalk processor is
accessible as an instance of class Process that owns a
chain of stack frames. The debugger is just a Smalltalk
subsystem that has access to manipulate the state of a
suspended process. It should be noted that nearly the
only run-time error that can occur in Smalltalk is for
a message not to be recognized by its receiver.
Smalltalk has no "operation system" as such. The
necessary primitive operations, such as reading a page
from the disk, are incorporated as primitive methods in
response to otherwise normal Smalltalk messages.
And another little comment as regards Kay's "complaining" that Smalltalk had become "something to be learned": I very much failed to learn computer science from high school Java, where classes, methods, encapsulation etc were treated as things-to-be-learned. I didn't know that I /could/ care about how they were put in place or why.
If I had been taught that everything in a meta-system can be changed when you structure your changes, I would have been a happier camper--motivated by autonomy and purpose.