7 ms·

The Object Model of Self

144 points by xkriva11 7y ago

artemonster 7y ago
Really nice explanation. Having read almost all papers on this endless debate "Classes vs Prototypes" you'd get a feeling that prototype-based object system wins in any aspects (expressiveness, flexibility, whatever), and yet almost all prototype-based languages in the end include crude class implementations (as Class for a signle namespace to contain all related traits, constructor method and/or prototypical instance for cloning) - interesting, why so? Is this model ingrained in our brains by our education or we do really think that way (i.e. with sets of related entities).
- chadcmulligan 7y ago
  I love the idea of prototypes, and self, but I always use classes. There's this idea of the self prototyping environment you can extend, which is great for prototyping (perhaps), but when it comes to professional programming we want a program to deploy and no one really touches the internal structure, so classes and deployment win out. The same for smalltalk, you don't want to deploy an environment that your users can extend - except perhaps in research environments. The other thing I suppose is multi developer environments - classes and compilation win out over prototyping because they're easier to split up. There might be other reasons, but that's why I always come back to class based programming, the idea of prototypes is very enticing though. Edit: though I have started to use a pseudo prototyping environment - breakpoints and evaluate when things get complex, though its not the same.
  - Lichtso 7y ago
    > you don't want to deploy an environment that your users can extend What is so bad about that? And isn't it common practice around computer games for example, which can be modded and extended by custom user content?
    - chadcmulligan 7y ago
      yes probably - but I suppose the limit there is controlling what they can extend? The other thing with games is performance - prototype languages are slower in general. I'm not against them - these are reasons I can see for not using prototype languages. Edit: I suppose to the environment a developer wants isn't the environment that a game user wants, like a game user wants to just extend a few things - but having the whole self environment for arguments sake would be fairly intimidating I'd imagine.
      - kazagistar 7y ago
        The nicest games to mod are the ones with languages that allow reflection to replace anything and everything.
    - scroot 7y ago
      This was the view of "what personal computing would be like" held by the original LRG team at PARC. There would be no distinction between "user" and "programmer," since using the system would at some level involve some type of programming. All of today's computing culture and the systems we use heavily reflect the opposite view. It's hard for us to imagine, since programming is a kind of scribal trade.
      - ken 7y ago
        I disagree that all of our computing systems keep them apart. We’ve got systems like Bash, and Excel. Even when I’m not doing “programming”, I’m doing programming. I wish more systems had that flexibility. Even when the average user isn’t writing programs in it (like the web), all of the long-lived platforms today are programmable.
        scroot 7y ago
        > all of the long-lived platforms today are programmable Sure, programmable by what today we'd call "programmers" but certainly not by "users." This is because programming has become a niche trade (as I said before, like a scribal culture). I'll give an example. Most users' experience with their host Operating System involves prodigious use of buttons. They know how buttons work and they know how to interact with them. But in all these OSes it is extremely difficult for a user to make a button that does something they want, then, say, place it on their desktop for future use. In the past there were really good attempts at authorship in computing media (which is more like what the LRG was going for with Smalltalk etc), including Hypercard. In the latter system, you could pop open a button and see how it worked in a comprehensible scripting language. You could copy the button and paste it somewhere else. You cannot do any of this with buttons in the major OSes. The capability is not there.* The only option available to "users" is to learn a full fledged, general purpose programming language with all the pitfalls that entails, which means learning build systems and all the rest. At that point they have to become what today we call a "programmer," ie a scribal-programmer. Our dominant systems have been explicitly designed for a strict delineation between scribal-programmers and consumer-users. That's the rub. * - AppleScript is a so-so attempt at this, but even that has been allowed to die on the vine.
  - xkriva11 7y ago
    A good trade-off is to have a prototype-based object system but use it as a class-based system. You can benefit from a rigid system structure, and organization like Smalltalk has (it is easier to make good tools for it) but use prototype-based features during debugging and where it really makes sense.
  - eru 7y ago
    It might be interesting for you to look at this issue from an functional programming point of view. With FP you can simulate both class based approaches and prototype based approaches. The slightly 'warped' perspective of the FP lens might give you more insights into your question. (I can expand, if you are interested.)
- Someone 7y ago
  ”wins in any aspects (expressiveness, flexibility, whatever)” One ‘whatever’ where it doesn’t win is in robustness. Code will make assumptions about various kinds of animal and fail when meeting a sheep with 5 legs, or a pig that can fly. You can solve that by testing for capabilities, but you would have to do that in many places, and make sure to cover all of them. And yes, that comes at the cost of flexibility. Your class model won’t support flying pigs until you consciously add such support.
  - artemonster 7y ago
    All of what you've said is applicable to classes as well, and even more so. This line of argumentation was used _against_ classes by Lieberman (if I remember clearly)
- Symmetry 7y ago
  Classes are less flexible so they're easier for programmers to reason about. That makes them better in any situation where you don't need that extra flexibility, which is most of them.
- mntmoss 7y ago
  It's the Rule of Least Power in action. [0] You don't want to have extreme degrees of polymorphism the vast majority of the time. [0] https://en.m.wikipedia.org/wiki/Rule_of_least_power https://en.m.wikipedia.org/wiki/Rule_of_least_power
- culturedsystems 7y ago
  I don't think I've ever seen any purported examples of the expressiveness and flexibility of prototype-based OO where the advantage actually comes from being prototype based rather than class based. Rather, the flexibility comes from being a dynamic language with a first-class metamodel. Or, to put it more concretely: in what way is Self more expressive or flexible than Smalltalk?
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...
k__ 7y ago
I learned the object model of Smalltalk at university and after that I couldn't take most class based OOP languages seriously anymore. Everything felt like a hack. Protoypical OOP was the only savior left, haha.
dboreham 7y ago
Came here to read a psychology article..
scroot 7y ago
Anyone interested in prototype-based languages should also checkout io [1], which is a really clever implementation that doesn't get enough love. And unlike Self it will work with your favorite teletype emulation environments. [1] https://iolanguage.org/ https://iolanguage.org/
- masklinn 7y ago
  I've always been really troubled by io's `clone` not not actually cloning the object but creating a sub-object / subtype instead. As well as the prototypes being an array (so manipulating prototypes is not really a thing). Oh and it uses the same lingo as javascript, which is a net negative, I think the Self lingo makes much more sense: a Self prototype is the object you copy in order to get more instances, once the copy is done there is no relationship between the prototype and the object just as there is no strict relationship beyond kinship between your car and its original prototype. I guess "template" might have been an even better term there. The shared behaviour (and potentially data) lives in traits and mixins.
tyingq 7y ago
I really like Perl's setup where objects are nothing more than namespaces/packages (usable and helpful in non-oo Perl) and one function...bless()[1]. It makes it very easy to follow exactly how the OO works, what it is, and is not. [1] https://perldoc.perl.org/functions/bless.html https://perldoc.perl.org/functions/bless.html

144 points by xkriva11 7y ago

Really nice explanation. Having read almost all papers on this endless debate "Classes vs Prototypes" you'd get a feeling that prototype-based object system wins in any aspects (expressiveness, flexibility, whatever), and yet almost all prototype-based languages in the end include crude class implementations (as Class for a signle namespace to contain all related traits, constructor method and/or prototypical instance for cloning) - interesting, why so? Is this model ingrained in our brains by our education or we do really think that way (i.e. with sets of related entities).

chadcmulligan 7y ago
I love the idea of prototypes, and self, but I always use classes. There's this idea of the self prototyping environment you can extend, which is great for prototyping (perhaps), but when it comes to professional programming we want a program to deploy and no one really touches the internal structure, so classes and deployment win out. The same for smalltalk, you don't want to deploy an environment that your users can extend - except perhaps in research environments. The other thing I suppose is multi developer environments - classes and compilation win out over prototyping because they're easier to split up. There might be other reasons, but that's why I always come back to class based programming, the idea of prototypes is very enticing though. Edit: though I have started to use a pseudo prototyping environment - breakpoints and evaluate when things get complex, though its not the same.
- Lichtso 7y ago
  > you don't want to deploy an environment that your users can extend What is so bad about that? And isn't it common practice around computer games for example, which can be modded and extended by custom user content?
  - chadcmulligan 7y ago
    yes probably - but I suppose the limit there is controlling what they can extend? The other thing with games is performance - prototype languages are slower in general. I'm not against them - these are reasons I can see for not using prototype languages. Edit: I suppose to the environment a developer wants isn't the environment that a game user wants, like a game user wants to just extend a few things - but having the whole self environment for arguments sake would be fairly intimidating I'd imagine.
    - kazagistar 7y ago
      The nicest games to mod are the ones with languages that allow reflection to replace anything and everything.
  - scroot 7y ago
    This was the view of "what personal computing would be like" held by the original LRG team at PARC. There would be no distinction between "user" and "programmer," since using the system would at some level involve some type of programming. All of today's computing culture and the systems we use heavily reflect the opposite view. It's hard for us to imagine, since programming is a kind of scribal trade.
    - ken 7y ago
      I disagree that all of our computing systems keep them apart. We’ve got systems like Bash, and Excel. Even when I’m not doing “programming”, I’m doing programming. I wish more systems had that flexibility. Even when the average user isn’t writing programs in it (like the web), all of the long-lived platforms today are programmable.
      - scroot 7y ago
        > all of the long-lived platforms today are programmable Sure, programmable by what today we'd call "programmers" but certainly not by "users." This is because programming has become a niche trade (as I said before, like a scribal culture). I'll give an example. Most users' experience with their host Operating System involves prodigious use of buttons. They know how buttons work and they know how to interact with them. But in all these OSes it is extremely difficult for a user to make a button that does something they want, then, say, place it on their desktop for future use. In the past there were really good attempts at authorship in computing media (which is more like what the LRG was going for with Smalltalk etc), including Hypercard. In the latter system, you could pop open a button and see how it worked in a comprehensible scripting language. You could copy the button and paste it somewhere else. You cannot do any of this with buttons in the major OSes. The capability is not there.* The only option available to "users" is to learn a full fledged, general purpose programming language with all the pitfalls that entails, which means learning build systems and all the rest. At that point they have to become what today we call a "programmer," ie a scribal-programmer. Our dominant systems have been explicitly designed for a strict delineation between scribal-programmers and consumer-users. That's the rub. * - AppleScript is a so-so attempt at this, but even that has been allowed to die on the vine.
- xkriva11 7y ago
  A good trade-off is to have a prototype-based object system but use it as a class-based system. You can benefit from a rigid system structure, and organization like Smalltalk has (it is easier to make good tools for it) but use prototype-based features during debugging and where it really makes sense.
- eru 7y ago
  It might be interesting for you to look at this issue from an functional programming point of view. With FP you can simulate both class based approaches and prototype based approaches. The slightly 'warped' perspective of the FP lens might give you more insights into your question. (I can expand, if you are interested.)
Someone 7y ago
”wins in any aspects (expressiveness, flexibility, whatever)” One ‘whatever’ where it doesn’t win is in robustness. Code will make assumptions about various kinds of animal and fail when meeting a sheep with 5 legs, or a pig that can fly. You can solve that by testing for capabilities, but you would have to do that in many places, and make sure to cover all of them. And yes, that comes at the cost of flexibility. Your class model won’t support flying pigs until you consciously add such support.
- artemonster 7y ago
  All of what you've said is applicable to classes as well, and even more so. This line of argumentation was used _against_ classes by Lieberman (if I remember clearly)
Symmetry 7y ago
Classes are less flexible so they're easier for programmers to reason about. That makes them better in any situation where you don't need that extra flexibility, which is most of them.
mntmoss 7y ago
It's the Rule of Least Power in action. [0] You don't want to have extreme degrees of polymorphism the vast majority of the time. [0] https://en.m.wikipedia.org/wiki/Rule_of_least_power https://en.m.wikipedia.org/wiki/Rule_of_least_power
culturedsystems 7y ago
I don't think I've ever seen any purported examples of the expressiveness and flexibility of prototype-based OO where the advantage actually comes from being prototype based rather than class based. Rather, the flexibility comes from being a dynamic language with a first-class metamodel. Or, to put it more concretely: in what way is Self more expressive or flexible than Smalltalk?

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...

k__ 7y ago

I learned the object model of Smalltalk at university and after that I couldn't take most class based OOP languages seriously anymore. Everything felt like a hack. Protoypical OOP was the only savior left, haha.

dboreham 7y ago

Came here to read a psychology article..

scroot 7y ago

Anyone interested in prototype-based languages should also checkout io [1], which is a really clever implementation that doesn't get enough love. And unlike Self it will work with your favorite teletype emulation environments. [1] https://iolanguage.org/ https://iolanguage.org/

masklinn 7y ago
I've always been really troubled by io's `clone` not not actually cloning the object but creating a sub-object / subtype instead. As well as the prototypes being an array (so manipulating prototypes is not really a thing). Oh and it uses the same lingo as javascript, which is a net negative, I think the Self lingo makes much more sense: a Self prototype is the object you copy in order to get more instances, once the copy is done there is no relationship between the prototype and the object just as there is no strict relationship beyond kinship between your car and its original prototype. I guess "template" might have been an even better term there. The shared behaviour (and potentially data) lives in traits and mixins.

tyingq 7y ago

I really like Perl's setup where objects are nothing more than namespaces/packages (usable and helpful in non-oo Perl) and one function...bless()[1]. It makes it very easy to follow exactly how the OO works, what it is, and is not. [1] https://perldoc.perl.org/functions/bless.html https://perldoc.perl.org/functions/bless.html