4 ms·

I was super obsessed with Self about 15 years ago. JavaScript's prototypal inheritance was influenced by Self. I was more interested in Self's graphical environ

by fzzzy 7y ago

I was super obsessed with Self about 15 years ago. JavaScript's prototypal inheritance was influenced by Self. I was more interested in Self's graphical environment at the time, though.

masklinn 7y ago
> JavaScript's prototypal inheritance was influenced by Self. Sadly more as a shortcut to getting an "object system" up and running quickly than as a design principle though, most of the interesting bits of Self were left by the wayside in the process (possibly in part to provide something which feels more like Java). Not to mention the subtle (and not necessarily sensible) terminological swaps e.g. in Self a prototype is a "blueprint" instance, which is already set up with all relevant traits & mixins, and gets copied and modified to get the proper instance.
- fzzzy 7y ago
  Yes, this is true. My point is Self's influence lives on. Also, Self's JIT was very influential and was the forerunner to Java JIT research. Copying and modifying the blueprint always did make way more sense. To this day I still don't think I understand exactly how JavaScript's prototypes work, exactly.
  - masklinn 7y ago
    Javascript's "prototype" is really Self's "trait". Self prototypes have been replaced by constructors which rather than be normal instances are special constructs building instances then setting their prototype property as the (sole) parent to the new instance. You can partially replicate Self's mechanism by performing a regular shallow-copy (e.g. using `Object.assign(target, source)` then explicitly copying over the prototype (that's fallible as Object.assign only copies the values of enumerable own properties so it's not going to copy the properties themselves).
  - ChrisSD 7y ago
    To expand on masklinn's point, Javascript's prototypes are actually very simple. It's just people overcomplicated it so as to do things it wasn't designed for (e.g. emulate Java classes). These points covers most of what a prototype is: 1. A prototype is simply another object (or null). 2. Every object can have one (and only one) prototype. 3. When looking up a property that doesn't exist on the object, the object will delegate to its prototype. 4. When calling a function on an object, the `this` keyword will be bound to that object, even if the function is defined in the object's prototype. A simple example to explain what I mean: // Provide a default implementation of a kitten const kitten = { name: "unnamed :(", greet() { // Note that `this` will be bound to // the object that invoked the method console.log(`Meow! I'm ${this.name}.`); } } // Create a named kitten. // `Object.create` creates a new object and sets // its prototype. const grabbity = Object.create(kitten); grabbity.name = "Grabbity"; // Call `greet` on the kittens. kitten.greet(); // outputs "Meow! I'm unnamed :(." grabbity.greet(); // outputs "Meow! I'm Grabbity." The only other thing to mention is something you can probably infer: Every prototype is an object therefore a prototype can have its own prototype (and so on). In this way prototypes can be chained.
- protomyth 7y ago
  I thought NewtonScript was a much more interesting descendent of Self than JavaScript. The concept of frames, dual inheritance hierarchy, and the Soup object database really set it apart. The papers on NewtonScript are still interesting reading.
  - fzzzy 7y ago
    I completely forgot about NewtonScript! I wonder if NewtonScript's containment inheritance was influenced by HyperTalk. Seems likely.
    - protomyth 7y ago
      I think it was more self. The UI paper is informative: https://cdn.preterhuman.net/texts/computing/apple/newton/Prototype-Based_Language_for_User_Interface_-_Newton_Projects_Experience.pdf https://cdn.preterhuman.net/texts/computing/apple/newton/Pro...
  - Ididntdothis 7y ago
    I did a lot of work on the Newton and NewtonScript was pretty cool. Soups were a really nice way of storing application data.
- AriaMinaei 7y ago
  > most of the interesting bits of Self were left by the wayside in the process A short summary of those interesting bits would be a nice read for us JS devs :)
  - kerkeslager 7y ago
    You should check out JavaScript: The Good Parts by Douglas Crockford. I'm not sure about later editions, but the first edition, published in 2008, predates a lot of the changes which left behind the better features of Self. The last 10 years have seen a large influx of users who didn't ever bother to grok the older feature set of JavaScript, and demanded features they had learned in Java and other languages (i.e. class-based inheritance) and language developers have obliged. The result is a language with both systems, and there's enough inconsistencies between the two that it doesn't make sense to use both in the same codebase. My advice would be to stick with the class-based features that are more common/popular today because your coworkers will be familiar with them: mixing in prototypical and class-based systems will just result in an incoherent system. Learn the Self features because they're interesting, but be very cautious about introducing them into modern JS codebases.
- kerkeslager 7y ago
  I'm not sure that I agree that it was a shortcut for the original creators or older users of JS. Lots of people (myself included) built stuff using self-style prototypical inheritance and argued against adding Java-style classes and inheritance, since they pollute the cleaner prototypical model with a bunch of inconsistencies (not necessarily worse, just inconsistent). We only really lost that argument with ES6 about 4 years ago.
  - masklinn 7y ago
    > I'm not sure that I agree that it was a shortcut for the original creators or older users of JS. There literally were no users when the object system was created. > they pollute the cleaner prototypical model Javascript’s « prototypal » model is not in any way clean, and all ES6 does is add useful and convenient syntactic shortcuts. The changes to the underlying model are improvements (eg official read/write access to the one lonely parent slot, ability to create objects without a parent, …)
    - kerkeslager 7y ago
      > There literally were no users when the object system was created. True, but it's odd that you say that as if it is disagreement with what you quoted. > Javascript’s « prototypal » model is not in any way clean, What's not clean about it? > and all ES6 does is add useful and convenient syntactic shortcuts. ES6 added shortcuts that are only useful and convenient if you didn't bother to learn the prototypical inheritance way of doing things, and wanted to do the things in the Java class-based style. > The changes to the underlying model are improvements (eg official read/write access to the one lonely parent slot, ability to create objects without a parent, …) Sure, agreed I guess.

by fzzzy 7y ago

I was super obsessed with Self about 15 years ago. JavaScript's prototypal inheritance was influenced by Self. I was more interested in Self's graphical environment at the time, though.

masklinn 7y ago

> JavaScript's prototypal inheritance was influenced by Self. Sadly more as a shortcut to getting an "object system" up and running quickly than as a design principle though, most of the interesting bits of Self were left by the wayside in the process (possibly in part to provide something which feels more like Java). Not to mention the subtle (and not necessarily sensible) terminological swaps e.g. in Self a prototype is a "blueprint" instance, which is already set up with all relevant traits & mixins, and gets copied and modified to get the proper instance.

fzzzy 7y ago
Yes, this is true. My point is Self's influence lives on. Also, Self's JIT was very influential and was the forerunner to Java JIT research. Copying and modifying the blueprint always did make way more sense. To this day I still don't think I understand exactly how JavaScript's prototypes work, exactly.
- masklinn 7y ago
  Javascript's "prototype" is really Self's "trait". Self prototypes have been replaced by constructors which rather than be normal instances are special constructs building instances then setting their prototype property as the (sole) parent to the new instance. You can partially replicate Self's mechanism by performing a regular shallow-copy (e.g. using `Object.assign(target, source)` then explicitly copying over the prototype (that's fallible as Object.assign only copies the values of enumerable own properties so it's not going to copy the properties themselves).
- ChrisSD 7y ago
  To expand on masklinn's point, Javascript's prototypes are actually very simple. It's just people overcomplicated it so as to do things it wasn't designed for (e.g. emulate Java classes). These points covers most of what a prototype is: 1. A prototype is simply another object (or null). 2. Every object can have one (and only one) prototype. 3. When looking up a property that doesn't exist on the object, the object will delegate to its prototype. 4. When calling a function on an object, the `this` keyword will be bound to that object, even if the function is defined in the object's prototype. A simple example to explain what I mean: // Provide a default implementation of a kitten const kitten = { name: "unnamed :(", greet() { // Note that `this` will be bound to // the object that invoked the method console.log(`Meow! I'm ${this.name}.`); } } // Create a named kitten. // `Object.create` creates a new object and sets // its prototype. const grabbity = Object.create(kitten); grabbity.name = "Grabbity"; // Call `greet` on the kittens. kitten.greet(); // outputs "Meow! I'm unnamed :(." grabbity.greet(); // outputs "Meow! I'm Grabbity." The only other thing to mention is something you can probably infer: Every prototype is an object therefore a prototype can have its own prototype (and so on). In this way prototypes can be chained.
protomyth 7y ago
I thought NewtonScript was a much more interesting descendent of Self than JavaScript. The concept of frames, dual inheritance hierarchy, and the Soup object database really set it apart. The papers on NewtonScript are still interesting reading.
- fzzzy 7y ago
  I completely forgot about NewtonScript! I wonder if NewtonScript's containment inheritance was influenced by HyperTalk. Seems likely.
  - protomyth 7y ago
    I think it was more self. The UI paper is informative: https://cdn.preterhuman.net/texts/computing/apple/newton/Prototype-Based_Language_for_User_Interface_-_Newton_Projects_Experience.pdf https://cdn.preterhuman.net/texts/computing/apple/newton/Pro...
- Ididntdothis 7y ago
  I did a lot of work on the Newton and NewtonScript was pretty cool. Soups were a really nice way of storing application data.
AriaMinaei 7y ago
> most of the interesting bits of Self were left by the wayside in the process A short summary of those interesting bits would be a nice read for us JS devs :)
- kerkeslager 7y ago
  You should check out JavaScript: The Good Parts by Douglas Crockford. I'm not sure about later editions, but the first edition, published in 2008, predates a lot of the changes which left behind the better features of Self. The last 10 years have seen a large influx of users who didn't ever bother to grok the older feature set of JavaScript, and demanded features they had learned in Java and other languages (i.e. class-based inheritance) and language developers have obliged. The result is a language with both systems, and there's enough inconsistencies between the two that it doesn't make sense to use both in the same codebase. My advice would be to stick with the class-based features that are more common/popular today because your coworkers will be familiar with them: mixing in prototypical and class-based systems will just result in an incoherent system. Learn the Self features because they're interesting, but be very cautious about introducing them into modern JS codebases.
kerkeslager 7y ago
I'm not sure that I agree that it was a shortcut for the original creators or older users of JS. Lots of people (myself included) built stuff using self-style prototypical inheritance and argued against adding Java-style classes and inheritance, since they pollute the cleaner prototypical model with a bunch of inconsistencies (not necessarily worse, just inconsistent). We only really lost that argument with ES6 about 4 years ago.
- masklinn 7y ago
  > I'm not sure that I agree that it was a shortcut for the original creators or older users of JS. There literally were no users when the object system was created. > they pollute the cleaner prototypical model Javascript’s « prototypal » model is not in any way clean, and all ES6 does is add useful and convenient syntactic shortcuts. The changes to the underlying model are improvements (eg official read/write access to the one lonely parent slot, ability to create objects without a parent, …)
  - kerkeslager 7y ago
    > There literally were no users when the object system was created. True, but it's odd that you say that as if it is disagreement with what you quoted. > Javascript’s « prototypal » model is not in any way clean, What's not clean about it? > and all ES6 does is add useful and convenient syntactic shortcuts. ES6 added shortcuts that are only useful and convenient if you didn't bother to learn the prototypical inheritance way of doing things, and wanted to do the things in the Java class-based style. > The changes to the underlying model are improvements (eg official read/write access to the one lonely parent slot, ability to create objects without a parent, …) Sure, agreed I guess.