4 ms·

Very nice article. It seems most developers don't likes how prototype based object model works in JS. I wonder how Javascript object system compare to Self, or

by h8hawk 7y ago

Very nice article. It seems most developers don't likes how prototype based object model works in JS. I wonder how Javascript object system compare to Self, or similar language IO?

spinningslate 7y ago
+1 for highlighting Io [0] I've never done any real work with Io, only read about it. First came across it in 7 languages in 7 weeks[1]. Compared to JS, it seems like a much more coherent realisation of protypes. It recognises the difference between "types" - descriptions of things - and "objects" - exemplars of those descriptions. But the only difference (that I recall) is that types are capitalised by convention, objects aren't. On my "todo list" for further exploration st some point. [0] http://iolanguage.com/ http://iolanguage.com/ [1] https://pragprog.com/book/btlang/seven-languages-in-seven-weeks https://pragprog.com/book/btlang/seven-languages-in-seven-we... EDIT: fixed book title & corrected case
- cmrdporcupine 7y ago
  If I recall correctly, Steve was very influenced by Lua. So he wanted to make a compact and embeddable interpreter but with nice consistent OO semantics, like Smalltalk or Self. (My interest in prototype OO languages back then was specifically as authoring languages for shared virtual worlds so I wanted something with security baked in. The language I implemented accomplished this through very strong encapsulation, among other things.) Like I said above, it'd be nice to see something like Io done with Wasm in mind, as a cleaner alternative to JS, say.
cmrdporcupine 7y ago
I learned several prototype OO languages (Self, LambdaMOO and variants) before I learned JS back in the mid-90s. I even wrote my own compiler and VM for my own. My take is that JS's implementation of prototypes isn't terrible, but it's also not clear what it's doing all the time. Like many other things in JS the semantics are often odd (strange scoping rules, functions as construtors in certain contexts only, etc.) Many of the warts have smoothed over time, but JS got a reputation for being an ugly hack language early on, and unfortunately that also rubbed off on the idea of prototype OO. I remember hearing a lot of griping about how JS isn't a "real OO" language (!#@!@#!@) because it only had prototypes and not classes. And a lot of rejoicing when classes were proposed for the language. Which to me was a sign of defeat. Prototypes are more expressive and can express classes but classes cannot express prototypes. FWIW I used to talk to and correspond with Steve Dekorte (author of Io) back when he was starting out. Looks like he's stopped working on it, which is unfortunate. It was always a nice language, though not suited for my purposes. And I think he chose a bad name as it wasn't easily Googleable. I'd like to see what he could do with it now in the era of Wasm...
- sergeykish 7y ago
  I agree, interface is arcane but once it clicks... And that may be a problem - world divided by those who grasped that Object.__proto__ === Function.prototype and other. I've heard similar stories in XSLT land. What if interface matters? Just recently I've discovered how to clear some confusion: Object Object.proto === null object = new Object object.proto === Object object.toString === Object.toString fun = new Function fun.proto === Function It's almost io (just don't touch 'constructor') Object = Object.prototype Function = Function.prototype syntax new = function (ctx) { let ident = ctx.next().value return #`new ${ident}.constructor` } // bonus point - make it more like io Reflect.defineProperty(Object, 'proto', Reflect.getOwnPropertyDescriptor(Object, '__proto__')) And io is great!
masklinn 7y ago
> I wonder how Javascript object system compare to Self, or similar language IO? It's limited, confusing and muddled, because the prototypal stuff was really there for the ease of implementing an object system (until ES6 the prototype was the red-headed stepchild of the language standards-wise) and ctors were tacked on for familiarity with Java but actual inheritance support (actually supporting JS-level subtypes) was all half-assed and very confusing before ES6. Basically pre-ES6 it was a complete mess unless you used non-standard extensions (e.g. `__proto__`). ES6 both dramatically surfaced the prototypal inheritance (Object.create, Object.getPrototypeOf, Object.setPrototypeOf, Object.defineProperty) and made it even more of an implementation detail of the "class" syntactic sugar. Nowadays you can pretty much use JS as a class-based language… and most people do that because frankly it's not worth messing around with the underlying prototypal system, you'll just confuse both your colleagues and your editor.
- ChrisSD 7y ago
  I think you're mixing up your timelines. ES5 brought `Object.create` and other prototype helper methods. This was a heyday, of sorts, for JS as a prototypal language with Crockford and others trying to explain how prototypes differ from inheritance based classes. However even then the C++/Java model had become too well ingrained by that point, especially at certain very large tech companies. The `class` keyword was introduced in ES6, which is indeed a kludge on top of prototypes.
  - masklinn 7y ago
    > I think you're mixing up your timelines. ES5 brought `Object.create` and other prototype helper methods. You’re right, I did. So the actual timeline was somewhat less dim than I remembered. > The `class` keyword was introduced in ES6, which is indeed a kludge on top of prototypes. I wouldn’t say that it’s a kludge. I’d anything it’s more of a realisation of the original vision of JavaScript (which you could fairly call a kludge): using a prototype system to underlie a langage approaching java semantics. Which may well be the dumbest way to approach it as you get the flexibility of a class-based system and the performances of a prototype-based system rather than the other way around, but at the same time JS’s prototype system was kneecapped from the start.

by h8hawk 7y ago

Very nice article. It seems most developers don't likes how prototype based object model works in JS. I wonder how Javascript object system compare to Self, or similar language IO?

spinningslate 7y ago

+1 for highlighting Io [0] I've never done any real work with Io, only read about it. First came across it in 7 languages in 7 weeks[1]. Compared to JS, it seems like a much more coherent realisation of protypes. It recognises the difference between "types" - descriptions of things - and "objects" - exemplars of those descriptions. But the only difference (that I recall) is that types are capitalised by convention, objects aren't. On my "todo list" for further exploration st some point. [0] http://iolanguage.com/ http://iolanguage.com/ [1] https://pragprog.com/book/btlang/seven-languages-in-seven-weeks https://pragprog.com/book/btlang/seven-languages-in-seven-we... EDIT: fixed book title & corrected case

cmrdporcupine 7y ago
If I recall correctly, Steve was very influenced by Lua. So he wanted to make a compact and embeddable interpreter but with nice consistent OO semantics, like Smalltalk or Self. (My interest in prototype OO languages back then was specifically as authoring languages for shared virtual worlds so I wanted something with security baked in. The language I implemented accomplished this through very strong encapsulation, among other things.) Like I said above, it'd be nice to see something like Io done with Wasm in mind, as a cleaner alternative to JS, say.

cmrdporcupine 7y ago

I learned several prototype OO languages (Self, LambdaMOO and variants) before I learned JS back in the mid-90s. I even wrote my own compiler and VM for my own. My take is that JS's implementation of prototypes isn't terrible, but it's also not clear what it's doing all the time. Like many other things in JS the semantics are often odd (strange scoping rules, functions as construtors in certain contexts only, etc.) Many of the warts have smoothed over time, but JS got a reputation for being an ugly hack language early on, and unfortunately that also rubbed off on the idea of prototype OO. I remember hearing a lot of griping about how JS isn't a "real OO" language (!#@!@#!@) because it only had prototypes and not classes. And a lot of rejoicing when classes were proposed for the language. Which to me was a sign of defeat. Prototypes are more expressive and can express classes but classes cannot express prototypes. FWIW I used to talk to and correspond with Steve Dekorte (author of Io) back when he was starting out. Looks like he's stopped working on it, which is unfortunate. It was always a nice language, though not suited for my purposes. And I think he chose a bad name as it wasn't easily Googleable. I'd like to see what he could do with it now in the era of Wasm...

sergeykish 7y ago
I agree, interface is arcane but once it clicks... And that may be a problem - world divided by those who grasped that Object.__proto__ === Function.prototype and other. I've heard similar stories in XSLT land. What if interface matters? Just recently I've discovered how to clear some confusion: Object Object.proto === null object = new Object object.proto === Object object.toString === Object.toString fun = new Function fun.proto === Function It's almost io (just don't touch 'constructor') Object = Object.prototype Function = Function.prototype syntax new = function (ctx) { let ident = ctx.next().value return #`new ${ident}.constructor` } // bonus point - make it more like io Reflect.defineProperty(Object, 'proto', Reflect.getOwnPropertyDescriptor(Object, '__proto__')) And io is great!

masklinn 7y ago

> I wonder how Javascript object system compare to Self, or similar language IO? It's limited, confusing and muddled, because the prototypal stuff was really there for the ease of implementing an object system (until ES6 the prototype was the red-headed stepchild of the language standards-wise) and ctors were tacked on for familiarity with Java but actual inheritance support (actually supporting JS-level subtypes) was all half-assed and very confusing before ES6. Basically pre-ES6 it was a complete mess unless you used non-standard extensions (e.g. `__proto__`). ES6 both dramatically surfaced the prototypal inheritance (Object.create, Object.getPrototypeOf, Object.setPrototypeOf, Object.defineProperty) and made it even more of an implementation detail of the "class" syntactic sugar. Nowadays you can pretty much use JS as a class-based language… and most people do that because frankly it's not worth messing around with the underlying prototypal system, you'll just confuse both your colleagues and your editor.

ChrisSD 7y ago
I think you're mixing up your timelines. ES5 brought `Object.create` and other prototype helper methods. This was a heyday, of sorts, for JS as a prototypal language with Crockford and others trying to explain how prototypes differ from inheritance based classes. However even then the C++/Java model had become too well ingrained by that point, especially at certain very large tech companies. The `class` keyword was introduced in ES6, which is indeed a kludge on top of prototypes.
- masklinn 7y ago
  > I think you're mixing up your timelines. ES5 brought `Object.create` and other prototype helper methods. You’re right, I did. So the actual timeline was somewhat less dim than I remembered. > The `class` keyword was introduced in ES6, which is indeed a kludge on top of prototypes. I wouldn’t say that it’s a kludge. I’d anything it’s more of a realisation of the original vision of JavaScript (which you could fairly call a kludge): using a prototype system to underlie a langage approaching java semantics. Which may well be the dumbest way to approach it as you get the flexibility of a class-based system and the performances of a prototype-based system rather than the other way around, but at the same time JS’s prototype system was kneecapped from the start.