2 ms·

> message passing and late binding combined. "Duck typing" is seriously diminishing it Actually even ST-72 made synchronous calls, but at least with a token st

by Rochus 4y ago

> message passing and late binding combined. "Duck typing" is seriously diminishing it Actually even ST-72 made synchronous calls, but at least with a token stream interpreted by the receiving object (thus at least a bit of "message passing"). In ST-76 and later versions "message passing" is just nomenclature used by the ST folks for something that is just ordinary method dispatch and call (if you have doubts, you can analyze the innards of the ST-80 VM yourself e.g. with these tools: https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk ). The major difference is the dispatch based on signature hash (similar to e.g. Java interface method calls) instead of static offsets, which enables late binding (at the expense of performance); and since everything including ordinary integers derive from Object, all values and objects are subject to dynamic method dispatch; it's no coincidence that Smalltalk was the first language to be associated with duck typing. The unification of scalar values and references, dynamic typing, and likewise the minimal syntax where control structures are implemented by means of runtime constructs were already known from Lisp; also closures (i.e. ST blocks) were already known before they were added to ST.

vidarh 4y ago
> Actually even ST-72 made synchronous calls I've not suggested it is anything but synchronous, so I don't know why you're bringing that up. It's not what we're talking about when we talk about "message passing" in this context. > In ST-76 and later versions "message passing" is just nomenclature used by the ST folks for something that is just ordinary method dispatch and call (if you have doubts, you can analyze the innards of the ST-80 VM yourself e.g. with these tools: https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk ). Sure, you can implement method dispatch the same way. I've written a (partial; unfinished; very buggy) Ruby compiler that allows dynamic method redefinition with even basic C++-style vtables. The point is not the dispatch method but the ability to override them at will. > The major difference is the dispatch based on signature hash (similar to e.g. Java interface method calls) instead of static offsets, which enables late binding That late binding is an important part of it. But you don't even need to deviate from static offsets to enable that late binding (you do need to do so if you want the ability to do dynamic interface-based inheritance, but even then you can use a vtable-like approach - see e.g. Protocol Extension: A Technique for Structuring Large Extensible Software-Systems, M. Franz, 1995 - which adds dynamic inheritance at runtime to Oberon) as long as the dictionaries/vtables/whatever you look them up in are mutable.
- Rochus 4y ago
  Which closes the loop to my point, that Simula 67 is much closer to the mainstream OO concepts we see in C++, Java, C# and Python than Smalltalk, and there is no reason to elevate Self (nor ST) as the "ur OO language".
  - vidarh 4y ago
    Which I agreed with you is a reasonable stance. To quote myself: > Ii is, because it inspired both the Smalltalk branch and the more mainstream OO languages, and hence it makes sense to consider it as a possible ur-language in that sense. I then went on to argue simply that because Smalltalk is at the root of a significant branch, I wouldn't have an issue with considering that an ur-language if one considers that branch important enough and/or consider message passing and late binding to be essential for a language to be object oriented, as opposed to having some object oriented features. But I went on to again agree with you: > I agree with you that Simula at least on the surface will seem more familiar to people familiar with ALGOL-derived languages with OO mechanisms than to Smalltalk. To sum it up: I've argued that a reasonable case can be made either for Simula or Smalltalk depending on how you define OO, but that no well established definition of OO would make Self a reasonable candidate.

by Rochus 4y ago

vidarh 4y ago

> Actually even ST-72 made synchronous calls I've not suggested it is anything but synchronous, so I don't know why you're bringing that up. It's not what we're talking about when we talk about "message passing" in this context. > In ST-76 and later versions "message passing" is just nomenclature used by the ST folks for something that is just ordinary method dispatch and call (if you have doubts, you can analyze the innards of the ST-80 VM yourself e.g. with these tools: https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk ). Sure, you can implement method dispatch the same way. I've written a (partial; unfinished; very buggy) Ruby compiler that allows dynamic method redefinition with even basic C++-style vtables. The point is not the dispatch method but the ability to override them at will. > The major difference is the dispatch based on signature hash (similar to e.g. Java interface method calls) instead of static offsets, which enables late binding That late binding is an important part of it. But you don't even need to deviate from static offsets to enable that late binding (you do need to do so if you want the ability to do dynamic interface-based inheritance, but even then you can use a vtable-like approach - see e.g. Protocol Extension: A Technique for Structuring Large Extensible Software-Systems, M. Franz, 1995 - which adds dynamic inheritance at runtime to Oberon) as long as the dictionaries/vtables/whatever you look them up in are mutable.

Rochus 4y ago
Which closes the loop to my point, that Simula 67 is much closer to the mainstream OO concepts we see in C++, Java, C# and Python than Smalltalk, and there is no reason to elevate Self (nor ST) as the "ur OO language".
- vidarh 4y ago
  Which I agreed with you is a reasonable stance. To quote myself: > Ii is, because it inspired both the Smalltalk branch and the more mainstream OO languages, and hence it makes sense to consider it as a possible ur-language in that sense. I then went on to argue simply that because Smalltalk is at the root of a significant branch, I wouldn't have an issue with considering that an ur-language if one considers that branch important enough and/or consider message passing and late binding to be essential for a language to be object oriented, as opposed to having some object oriented features. But I went on to again agree with you: > I agree with you that Simula at least on the surface will seem more familiar to people familiar with ALGOL-derived languages with OO mechanisms than to Smalltalk. To sum it up: I've argued that a reasonable case can be made either for Simula or Smalltalk depending on how you define OO, but that no well established definition of OO would make Self a reasonable candidate.