3 ms·

JavaScript in a browser + DevTools offer a similar environment to Smalltalk + Squeak. Sure, they're "similar", but at a relatively low approximation. The capab

JavaScript in a browser + DevTools offer a similar environment to Smalltalk + Squeak. 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.

mbrock 12y ago
Can you formulate more precisely (or by example) what you mean by "simply on a different plane"?
- vezzy-fnord 12y ago
  See the Design Principles Behind Smalltalk article: https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.... 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. This is from 1981, BTW.
frik 12y ago
That were just examples. 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
- discreteevent 12y ago
  ” 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” 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)
  - frik 12y ago
    Not really. Your first paragraph is also true for JS (think of ES6 "class" syntactic sugar). Some browsers implement the DOM in JavaScript (https://www.chromium.org/blink/blink-in-js https://www.chromium.org/blink/blink-in-js, http://www.phantomjs.org/ http://www.phantomjs.org/, https://github.com/andreasgal/dom.js https://github.com/andreasgal/dom.js). And there are things like asm.js and even Linux VM running in JavaScript (http://bellard.org/jslinux/ http://bellard.org/jslinux/). JavaScript/ECMAScript is one of the most misunderstood languages, please read up before jump at conclusions.
- riffraff 12y ago
  > 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. not in languages where you can control method dispatch and object allocation (smalltalk, ruby, python etc), than it's quite trivial.

mbrock 12y ago

Can you formulate more precisely (or by example) what you mean by "simply on a different plane"?

vezzy-fnord 12y ago
See the Design Principles Behind Smalltalk article: https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.... 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. This is from 1981, BTW.

frik 12y ago

That were just examples. 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

discreteevent 12y ago
” 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” 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)
- frik 12y ago
  Not really. Your first paragraph is also true for JS (think of ES6 "class" syntactic sugar). Some browsers implement the DOM in JavaScript (https://www.chromium.org/blink/blink-in-js https://www.chromium.org/blink/blink-in-js, http://www.phantomjs.org/ http://www.phantomjs.org/, https://github.com/andreasgal/dom.js https://github.com/andreasgal/dom.js). And there are things like asm.js and even Linux VM running in JavaScript (http://bellard.org/jslinux/ http://bellard.org/jslinux/). JavaScript/ECMAScript is one of the most misunderstood languages, please read up before jump at conclusions.
riffraff 12y ago
> 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. not in languages where you can control method dispatch and object allocation (smalltalk, ruby, python etc), than it's quite trivial.