3 ms·

" each Smalltalk object is a recursion on the entire possibilities of the computer " This is true to a degree. But a Smalltalk or any OOP object makes much too

" each Smalltalk object is a recursion on the entire possibilities of the computer " This is true to a degree. But a Smalltalk or any OOP object makes much too many assumptions about the inputs it gets via "messages". Most fatally they make the assumption the inputs are similar objects as the recipient, programmed in same or similar programming language. Note: In Smalltalk everything is an Object. A Computer instead communicates with other physical objects by means of a very simple binary protocol of ones and zeroes. The computer then interprets the bits it gets according to some generally agreed upon convention. A Smalltalk Object does not interpret the messages it gets, it assume they are already interpreted for it. The protocol of Smalltalk objects communicating with each other has not been implemented between computers in general. That is perhaps a failure of standardization, but it nevertheless is the reality. There are two ways to fix it: a) Make every Smalltalk object more like a computer in that it communicates with other objects only via a text-based protocol. not by passing along arguments with predefined semantics like Objects or Functions or Methods. b) Make every Computer assume the same of its inputs as a Smalltalk object makes of its. I think b) is impractical but maybe there could be a Smalltalk whose Objects truly act like small Computers.

tripleo1 4y ago
Is this why Smalltalk never has a multithreaded vm?
- galaxyLogic 4y ago
  Smalltalk implements its own threads which are instance of class Process. They are not OS-threads as far as I know.
- jdougan 4y ago
  Smalltalk/MT has platform threads
  - galaxyLogic 4y ago
    Good point forgot about that one. Now that you brought it up I realize that "MT" must refer to "MultiThreading". Do you know if Smalltalk/MT is still being maintained?
wahern 4y ago
> The protocol of Smalltalk objects communicating with each other has not been implemented between computers in general Not sure if this fits your conditions, but Croquet (https://en.wikipedia.org/wiki/Croquet_Project https://en.wikipedia.org/wiki/Croquet_Project) is a P2P, "distributed computation" architecture based on Smalltalk and the replication of messages (i.e. method calls) sent to object clones on participating nodes. The replication and commit protocol is called TeaTime (https://oneofus.la/have-emacs-will-hack/files/2005_Teatime_Framework_Design.pdf https://oneofus.la/have-emacs-will-hack/files/2005_Teatime_F...). Croquet is basically a 3D interactive WWW, but based on synchronized Smalltalk VM execution (distributed computation) rather than downloading data (e.g. HTML).
- galaxyLogic 4y ago
  Croquet and Teatime are great. If every computer would implement the Croquet protocol then that would be great. But my point is really that the protocol you use to interact with computers should be minimal and just typing in ascii characters on the terminal is about as minimal as possible. Characters are the transfer-level (ISO something?). By assuming that all inputs come as a string of (UTF?) characters we retain the maximum freedom as to how to interpret those characters. That makes computers very general purpose. The Smalltalk -protocol assumes some specific data-structures for representing the messages and results. Once you choose and require one such representation you would lose the ability to use any other representation, and thus we the ability to evolve ever more and multiple representations encoded as characters. Also, it is not Smalltalk Objects that do the interpretation of messages, like a Computer. It it is the Smalltalk runtime that does the interpretation. How we design the communication between humans and computers should be max flexible. This has something to do with JSON. JSON allows many different types of programs and computers interact with each other -- because it doesn't allow you to pass around Functions. JSON only passes basic data-structures. Therefore it is very general and flexible. Whoever gets a JSON-message is free to interpret the arrays, records and strings encoded as JSON in any way they want. Plain ASCII is even more general and flexible.

tripleo1 4y ago

Is this why Smalltalk never has a multithreaded vm?

galaxyLogic 4y ago
Smalltalk implements its own threads which are instance of class Process. They are not OS-threads as far as I know.
jdougan 4y ago
Smalltalk/MT has platform threads
- galaxyLogic 4y ago
  Good point forgot about that one. Now that you brought it up I realize that "MT" must refer to "MultiThreading". Do you know if Smalltalk/MT is still being maintained?

wahern 4y ago

> The protocol of Smalltalk objects communicating with each other has not been implemented between computers in general Not sure if this fits your conditions, but Croquet (https://en.wikipedia.org/wiki/Croquet_Project https://en.wikipedia.org/wiki/Croquet_Project) is a P2P, "distributed computation" architecture based on Smalltalk and the replication of messages (i.e. method calls) sent to object clones on participating nodes. The replication and commit protocol is called TeaTime (https://oneofus.la/have-emacs-will-hack/files/2005_Teatime_Framework_Design.pdf https://oneofus.la/have-emacs-will-hack/files/2005_Teatime_F...). Croquet is basically a 3D interactive WWW, but based on synchronized Smalltalk VM execution (distributed computation) rather than downloading data (e.g. HTML).

galaxyLogic 4y ago
Croquet and Teatime are great. If every computer would implement the Croquet protocol then that would be great. But my point is really that the protocol you use to interact with computers should be minimal and just typing in ascii characters on the terminal is about as minimal as possible. Characters are the transfer-level (ISO something?). By assuming that all inputs come as a string of (UTF?) characters we retain the maximum freedom as to how to interpret those characters. That makes computers very general purpose. The Smalltalk -protocol assumes some specific data-structures for representing the messages and results. Once you choose and require one such representation you would lose the ability to use any other representation, and thus we the ability to evolve ever more and multiple representations encoded as characters. Also, it is not Smalltalk Objects that do the interpretation of messages, like a Computer. It it is the Smalltalk runtime that does the interpretation. How we design the communication between humans and computers should be max flexible. This has something to do with JSON. JSON allows many different types of programs and computers interact with each other -- because it doesn't allow you to pass around Functions. JSON only passes basic data-structures. Therefore it is very general and flexible. Whoever gets a JSON-message is free to interpret the arrays, records and strings encoded as JSON in any way they want. Plain ASCII is even more general and flexible.