3 ms·

Sometimes I wonder if small talk had thrived how different the world might be. For example, we’ve experienced a trend over the last decade of building platform

Sometimes I wonder if small talk had thrived how different the world might be. For example, we’ve experienced a trend over the last decade of building platforms out of micro services. They have interfaces, which are sometimes statically typed and serialized with rpc libraries, and ultimately they send messages to each other, because they are isolated. Now imagine small talk. It’s virtually the same thing, but 50 years ago (and not networked). Still each object is isolated, and they only communicate by sending messages. Everything is an object that’s inspectable and can “independently deployed” by editing it in real time. This seems really nice. Are we living in a worse version of the world (technologically) than what we could have had? I don’t know a lot about small talk though so perhaps someone here can chime in and say why it wasn’t that great. To me though it seems like it was a serious system that was more than just a good demo. I can only imagine how it could have developed over 50 years if it was embraced. To me it still looks futuristic.

bruce343434 3y ago
What is the difference between "sending a smalltalk message" and "calling a method" (i.e., jumping the central thread of execution to a particular label until a ret instruction is reached)? This isn't truly distributed, it's still centralized. If one method gets stuck in a loop, the entire system grinds to a halt. If each "object" or "service" gets its own process or thread however, this doesn't happen, and you get graceful system degradation which can be mitigated by spinning up redundant services. You're right, most businesses don't need microservices, indeed "monolithic" (not distributed) architectures are totally fine and they have less overhead. And yeah probably a lot of businesses that do use microservices don't even make use of the benefits of a distributed system yet have all of the drawbacks. That's just people being people (stupid).
- t43562 3y ago
  If we wrote things as objects sending messages we might be able to disregard their remoteness most of the time. The value could be in writing software which wouldn't need to change much as you changed the way it's getting used radically. For a crappy example, a tool like rsync can talk to a copy of itself over any kind of stream and sync things that are remote so because it has this abstraction, you can rsync over ssh but you're not limited to ssh. If some future stream protocol arises rsync could probably be made to work over it without a rewrite.
- ryukafalz 3y ago
  If we had gone down the path of Smalltalk rather than the UNIX-like path we have taken, I imagine we'd see systems with asynchronous message-passing semantics using processes/threads. Think something like E (or now Spritely Goblins, which takes inspiration from it) with at least one separate vat per "application". This would result in a system like Smalltalk, but with concurrency to prevent the situation you're describing. I think we'd be in a much better place today had we taken that path, for a number of reasons.
- projektfu 3y ago
  In Smalltalk, calling a method is what the system does after a message is sent and the system looks up the receiver and its class hierarchy. This is a little different from C++ where the message dispatch is just vtable lookup by the calling code, because the system might have different behavior, such as changing the message to a #doesNotUnderstand: message. However, in your question it is not much different because the default approach is synchronous. Yes, the calling process waits for the receiver to send a response. This has been one of the sticking points of remoting objects since the beginning, that you cannot treat the network as completely transparent. The options are the same as in other languages: promises, callbacks, forking a process, etc. On the other hand, having a simple representation for network calls that the runtime can figure out for you automatically is pretty cool. You can ask Smalltalk to create proxies on the fly that act like the real thing but do the marshalling and network calls. The same was true for RMI in Java, which may have been based on Smalltalk and/or Modula-3. Comparing this to COM or CORBA, where the representation is defined externally, or to SOAP or some JSON api, where all bets are off, keeping everything in one system makes this stuff easy.
t43562 3y ago
Yes we are living in a worse version of the world that has come about because the more beautiful ideas didn't make it out in a wider way and with the right level of practicality-at-the-time to be scaled up. We probably will get there eventually but by a very very circuitous route.
fabioz 3y ago
I did work in Smalltalk in the university and I must say that in practice it was horrible to work with. It was very common to have the image corrupted -- imagine that you by mistake add a bug to your code. Now the live version you're dealing with is just unworkable and you have to find the last version that worked (because in practice the code you add is live with the code of your whole system in just a single place, so, anything bad you did affected not only your target env it also affected your dev env). -- version control was basically saving the whole image and no, you didn't have a way to diff 2 different images. I think that the current state where you edit text files and run your code based on those (and which you can sanely version control) and edit with a separate IDE is a much saner approach.
- asimpletune 3y ago
  Thanks for sharing your experience with working with Smalltalk. I wonder in a parallel universe, a smalltalk one, what VCS would have been like? Would the "last version that worked" also just have been an object?
  - nradov 3y ago
    Check out the Monticello VCS for Smalltalk. https://wiki.squeak.org/squeak/1287 https://wiki.squeak.org/squeak/1287
  - igouy 3y ago
    You've been given a mistaken impression of the Smalltalk-80 development process. Changes were automatically logged to an external text file and could be recovered. By the late '80s there was multi-user fine-grained version control: ENVY/Developer https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1 https://www.google.com/books/edition/Mastering_ENVY_Develope...
- BaseballPhysics 3y ago
  Fortunately things have changed in the intervening years. Pharo, for example, includes a complete git integration: https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/iceberg
walnutclosefarm 3y ago
Smalltalk was, and in many ways remains, my favorite programming language - as a language. But the image-based development environment, and the performance of the system, were both awful. As for message passing, and the potential for remote objects - well add CORBA into the mix of elegant, but ultimately unsustainable technologies alongside Smalltalk. The world was not ready for "pure" OO in the 80s, and I'm not sure it's ready now. Some things really are better in the mind, than in practice.

bruce343434 3y ago

What is the difference between "sending a smalltalk message" and "calling a method" (i.e., jumping the central thread of execution to a particular label until a ret instruction is reached)? This isn't truly distributed, it's still centralized. If one method gets stuck in a loop, the entire system grinds to a halt. If each "object" or "service" gets its own process or thread however, this doesn't happen, and you get graceful system degradation which can be mitigated by spinning up redundant services. You're right, most businesses don't need microservices, indeed "monolithic" (not distributed) architectures are totally fine and they have less overhead. And yeah probably a lot of businesses that do use microservices don't even make use of the benefits of a distributed system yet have all of the drawbacks. That's just people being people (stupid).

t43562 3y ago
If we wrote things as objects sending messages we might be able to disregard their remoteness most of the time. The value could be in writing software which wouldn't need to change much as you changed the way it's getting used radically. For a crappy example, a tool like rsync can talk to a copy of itself over any kind of stream and sync things that are remote so because it has this abstraction, you can rsync over ssh but you're not limited to ssh. If some future stream protocol arises rsync could probably be made to work over it without a rewrite.
ryukafalz 3y ago
If we had gone down the path of Smalltalk rather than the UNIX-like path we have taken, I imagine we'd see systems with asynchronous message-passing semantics using processes/threads. Think something like E (or now Spritely Goblins, which takes inspiration from it) with at least one separate vat per "application". This would result in a system like Smalltalk, but with concurrency to prevent the situation you're describing. I think we'd be in a much better place today had we taken that path, for a number of reasons.
projektfu 3y ago
In Smalltalk, calling a method is what the system does after a message is sent and the system looks up the receiver and its class hierarchy. This is a little different from C++ where the message dispatch is just vtable lookup by the calling code, because the system might have different behavior, such as changing the message to a #doesNotUnderstand: message. However, in your question it is not much different because the default approach is synchronous. Yes, the calling process waits for the receiver to send a response. This has been one of the sticking points of remoting objects since the beginning, that you cannot treat the network as completely transparent. The options are the same as in other languages: promises, callbacks, forking a process, etc. On the other hand, having a simple representation for network calls that the runtime can figure out for you automatically is pretty cool. You can ask Smalltalk to create proxies on the fly that act like the real thing but do the marshalling and network calls. The same was true for RMI in Java, which may have been based on Smalltalk and/or Modula-3. Comparing this to COM or CORBA, where the representation is defined externally, or to SOAP or some JSON api, where all bets are off, keeping everything in one system makes this stuff easy.

t43562 3y ago

Yes we are living in a worse version of the world that has come about because the more beautiful ideas didn't make it out in a wider way and with the right level of practicality-at-the-time to be scaled up. We probably will get there eventually but by a very very circuitous route.

fabioz 3y ago

I did work in Smalltalk in the university and I must say that in practice it was horrible to work with. It was very common to have the image corrupted -- imagine that you by mistake add a bug to your code. Now the live version you're dealing with is just unworkable and you have to find the last version that worked (because in practice the code you add is live with the code of your whole system in just a single place, so, anything bad you did affected not only your target env it also affected your dev env). -- version control was basically saving the whole image and no, you didn't have a way to diff 2 different images. I think that the current state where you edit text files and run your code based on those (and which you can sanely version control) and edit with a separate IDE is a much saner approach.

asimpletune 3y ago
Thanks for sharing your experience with working with Smalltalk. I wonder in a parallel universe, a smalltalk one, what VCS would have been like? Would the "last version that worked" also just have been an object?
- nradov 3y ago
  Check out the Monticello VCS for Smalltalk. https://wiki.squeak.org/squeak/1287 https://wiki.squeak.org/squeak/1287
- igouy 3y ago
  You've been given a mistaken impression of the Smalltalk-80 development process. Changes were automatically logged to an external text file and could be recovered. By the late '80s there was multi-user fine-grained version control: ENVY/Developer https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1 https://www.google.com/books/edition/Mastering_ENVY_Develope...
BaseballPhysics 3y ago
Fortunately things have changed in the intervening years. Pharo, for example, includes a complete git integration: https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/iceberg

walnutclosefarm 3y ago

Smalltalk was, and in many ways remains, my favorite programming language - as a language. But the image-based development environment, and the performance of the system, were both awful. As for message passing, and the potential for remote objects - well add CORBA into the mix of elegant, but ultimately unsustainable technologies alongside Smalltalk. The world was not ready for "pure" OO in the 80s, and I'm not sure it's ready now. Some things really are better in the mind, than in practice.