4 ms·

> That's not even close to a file system Nonetheless, Smalltalk is to Unix as globals dictionary is to file system, image is to virtual machine, etc. > How do

by tonyg 5y ago

> That's not even close to a file system Nonetheless, Smalltalk is to Unix as globals dictionary is to file system, image is to virtual machine, etc. > How do systems outside of Smalltalk get access to the Smalltalk global? How is such access mediated? How are permissions handled? What's more, if other systems could get access to a pointer (and it didn't move out from under them during a GC), how would they be able to deal with the data? How do systems outside of Unix get access to the file system? How is such access mediated? How are permissions handled? What's more, if other systems could get access to a disk sector (and it didn't move out from under them during normal system activity), how would they be able to deal with the data? Answer these questions, and you'll have answered those you asked about Smalltalk. If you squint a little.

abecedarius 5y ago
As Ingalls said, "An operating system is a collection of things that don’t fit into a language. There shouldn’t be one." (Yes, it's arguable.)
jrochkind1 5y ago
The OP is about envisioning Smalltalk and Unix working together. I'm not following your point of making analogies between Smalltalk and Unix, unless... Are you suggesting Smalltalk could have/should have/was a contender to be the OS, that it would replace unix, that would have been preferable?
- tonyg 5y ago
  IMO, Smalltalk-the-system is best thought of as an OS, yes. (Remember how everyone ridiculed the idea of Smalltalk's images right up until virtual machines became a thing?) It has a runtime and a systems programming language, too: the Smalltalk VM, and Smalltalk-the-language. Analogously, Unix has its kernel and C, respectively. The global variables of Smalltalk are analogous to Unix files. Smalltalk processes to Unix processes. It's not a perfect analogy but I found it surprisingly useful once I stumbled across it. Preferable, though? Not sure. Certainly, as Marcel notes, a flat file system isn't the best idea; but then, is a hierarchical strict tree? (Related: https://eighty-twenty.org/2011/05/08/weaknesses-of-smalltalk-strengths-of-erlang https://eighty-twenty.org/2011/05/08/weaknesses-of-smalltalk..., https://eighty-twenty.org/2016/05/05/unix-is-incorrectly-factored https://eighty-twenty.org/2016/05/05/unix-is-incorrectly-fac...) I think you'd have to burn the disk packs (ie: neither Smalltalk nor Unix as they stand make a suitable foundation), but out of the ashes I think something largely based on Smalltalk taking into account lessons from the forty (!) years that followed it could definitely end up being preferable. Coming back to OP, and viewing Smalltalk as an operating system on equal footing with Unix: Different operating systems interact best via networks. Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well.
  - jrochkind1 5y ago
    OK, so the OP says if smalltalk had worked with files better, maybe smalltalk on unix could have been a thing that would have changed history. Your response is... that's irrelevant because... smalltalk was really making the play to be the OS, not to work with OSs, and it works just fine with files on it's own terms, for that goal. Do I understand your argument correctly? OK, it's a perspective!
  - batman-farts 5y ago
    I think this is a worthwhile perspective. Looking at Pharo 9.0 circa 2021, it’s still got its own classes for Kernel, Scheduler, etc.
    - igouy 5y ago
      Which other programming language implementations have provided scheduling independent from the host OS? https://en.wikipedia.org/wiki/Green_threads https://en.wikipedia.org/wiki/Green_threads
    - deleted 5y ago
      [deleted]
  - mpweiher 5y ago
    > Smalltalk-the-system is best thought of as an OS That is the is that OP is lamenting, the fact that this attitude was a significant (not: sole) cause in Smalltalk's demise. He is talking about the ought, it shouldn't have been this way, and if it hadn't been this way it would have been a LOT better. Keep in mind that you can still build a pure Smalltalk OS on top of the Smalltalk that's not an OS, if you want to. > It's not a perfect analogy It is at best an analogy, and not a particularly good one at that, as whereas Smalltalk can function as an OS (you can port Squeak to bare metal fairly easily, for example), it isn't a very good at it, at least not when it comes to the functions OSes are expected to fulfil these days. And so the analogy stays at most an analogy, and breaks down even at that pretty quickly. It turns out that what OP was talking about was created, sort of: NeXTstep. Except it substituted Objective-C for Smalltalk. Heck, it even did messaging at the OS layer (Mach). > ...viewing Smalltalk as an operating system on equal footing with Unix... That is exactly the problem. > Different operating systems interact best via networks. And that turns out to be significantly more difficult than various languages interacting on the same box. > Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well. True. Objective-S supports REST servers and clients effectively at the language level. And filesystems and Unix pipes. http://objective.st/ http://objective.st/ And it doesn't insist on being the entire world.
- em-bee 5y ago
  i read it as mpweither arguing that the lack of interoperability is the fault of smalltalk, whereas tonyg points out that the fault might just as well be on the unix side. just as you are not going to blame unix that windows can't read a unix filesystem, it's not clear that smalltalk should be blamed that unix can't access a smalltalk image. if i want windows to access data on unix, then i write it to a filesystem that windows can read. likewise if i want a unix system to access the data inside a smalltalk image i need to write it from smalltalk to outside the image onto a unix filesystem. it's all a matter of how you look at it.
  - mpweiher 5y ago
    It's not a symmetric situation as these are not at the same level of the stack. Unix, as an OS, can and, maybe more importantly, does host a plethora of languages and even operating systems (as VMs). Smalltalk does not, and if you take the OS = language idea seriously, cannot. So Ruby can read Unix directories and files. Ruby cannot read Smalltalk "directories" (the Smalltalk dictionary) or files (objects). And Smalltalk cannot read Ruby objects. Python can read Unix directories and files. Python cannot read Smalltalk directories or files. And Smalltalk cannot read Python objects. Java can read Unix directories and files. Java cannot read Smalltalk directories or files. And Smalltalk cannot read Java objects. etc. All of these can interoperate fairly trivially (though possibly not particularly well) via the filesystem. They cannot (and could not, without significant effort) interoperate via Smalltalk.
    - em-bee 5y ago
      yes, i see your point. interaction of different system at the object level has been done before though and i think that is an area that could use more research and evolution to become usable.
      - mpweiher 5y ago
        > interaction of different system at the object level has been done before though Yes. I have used this (CocoaJava, Tcl/ObjC, Ruby/ObjC, etc.) and also implemented it myself (Squeak/Objective-C, among others). Even though I'd say that Objective-C is probably about as good at this as it gets, the end results are still complicated and fragile. In the end, what ends up most workable is that one object model is declared "it", and the rest of the languages then just skins on top of that object model. (See the various .NET languages and reimplementations, JVM languages and reimplementations, and now Truffle/Graal).
msla 5y ago
> How do systems outside of Unix get access to the file system? What is the Smalltalk equivalent to NFS?
- tonyg 5y ago
  If Smalltalk is pretending to be Unix, it could just speak NFS I suppose. Or use HTTP. Or 9P. Certainly there are classes in most images that model file systems. But thinking of Smalltalk as its own thing, and coming at the angle of interoperation between systems across networks at a higher level than chunks of untyped binary data, there are a few contenders: there have been various distributed Actor implementations. CORBA was available, back when that was relevant. Craig Latta has been doing some wonderful crazy things with interoperation between separate images (e.g. Context, nee Spoon: http://netjam.org/context/ http://netjam.org/context/).
  - smackeyacky 5y ago
    Ugh CORBA. It was more of a hindrance than a help when it came to interoperability.
    - pjmlp 5y ago
      Now it is back as gRPC.
- pjmlp 5y ago
  Xerox PARC own networking protocols https://en.m.wikipedia.org/wiki/Xerox_Star https://en.m.wikipedia.org/wiki/Xerox_Star

by tonyg 5y ago

abecedarius 5y ago

As Ingalls said, "An operating system is a collection of things that don’t fit into a language. There shouldn’t be one." (Yes, it's arguable.)

jrochkind1 5y ago

The OP is about envisioning Smalltalk and Unix working together. I'm not following your point of making analogies between Smalltalk and Unix, unless... Are you suggesting Smalltalk could have/should have/was a contender to be the OS, that it would replace unix, that would have been preferable?

tonyg 5y ago
IMO, Smalltalk-the-system is best thought of as an OS, yes. (Remember how everyone ridiculed the idea of Smalltalk's images right up until virtual machines became a thing?) It has a runtime and a systems programming language, too: the Smalltalk VM, and Smalltalk-the-language. Analogously, Unix has its kernel and C, respectively. The global variables of Smalltalk are analogous to Unix files. Smalltalk processes to Unix processes. It's not a perfect analogy but I found it surprisingly useful once I stumbled across it. Preferable, though? Not sure. Certainly, as Marcel notes, a flat file system isn't the best idea; but then, is a hierarchical strict tree? (Related: https://eighty-twenty.org/2011/05/08/weaknesses-of-smalltalk-strengths-of-erlang https://eighty-twenty.org/2011/05/08/weaknesses-of-smalltalk..., https://eighty-twenty.org/2016/05/05/unix-is-incorrectly-factored https://eighty-twenty.org/2016/05/05/unix-is-incorrectly-fac...) I think you'd have to burn the disk packs (ie: neither Smalltalk nor Unix as they stand make a suitable foundation), but out of the ashes I think something largely based on Smalltalk taking into account lessons from the forty (!) years that followed it could definitely end up being preferable. Coming back to OP, and viewing Smalltalk as an operating system on equal footing with Unix: Different operating systems interact best via networks. Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well.
- jrochkind1 5y ago
  OK, so the OP says if smalltalk had worked with files better, maybe smalltalk on unix could have been a thing that would have changed history. Your response is... that's irrelevant because... smalltalk was really making the play to be the OS, not to work with OSs, and it works just fine with files on it's own terms, for that goal. Do I understand your argument correctly? OK, it's a perspective!
- batman-farts 5y ago
  I think this is a worthwhile perspective. Looking at Pharo 9.0 circa 2021, it’s still got its own classes for Kernel, Scheduler, etc.
  - igouy 5y ago
    Which other programming language implementations have provided scheduling independent from the host OS? https://en.wikipedia.org/wiki/Green_threads https://en.wikipedia.org/wiki/Green_threads
  - deleted 5y ago
    [deleted]
- mpweiher 5y ago
  > Smalltalk-the-system is best thought of as an OS That is the is that OP is lamenting, the fact that this attitude was a significant (not: sole) cause in Smalltalk's demise. He is talking about the ought, it shouldn't have been this way, and if it hadn't been this way it would have been a LOT better. Keep in mind that you can still build a pure Smalltalk OS on top of the Smalltalk that's not an OS, if you want to. > It's not a perfect analogy It is at best an analogy, and not a particularly good one at that, as whereas Smalltalk can function as an OS (you can port Squeak to bare metal fairly easily, for example), it isn't a very good at it, at least not when it comes to the functions OSes are expected to fulfil these days. And so the analogy stays at most an analogy, and breaks down even at that pretty quickly. It turns out that what OP was talking about was created, sort of: NeXTstep. Except it substituted Objective-C for Smalltalk. Heck, it even did messaging at the OS layer (Mach). > ...viewing Smalltalk as an operating system on equal footing with Unix... That is exactly the problem. > Different operating systems interact best via networks. And that turns out to be significantly more difficult than various languages interacting on the same box. > Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well. True. Objective-S supports REST servers and clients effectively at the language level. And filesystems and Unix pipes. http://objective.st/ http://objective.st/ And it doesn't insist on being the entire world.
em-bee 5y ago
i read it as mpweither arguing that the lack of interoperability is the fault of smalltalk, whereas tonyg points out that the fault might just as well be on the unix side. just as you are not going to blame unix that windows can't read a unix filesystem, it's not clear that smalltalk should be blamed that unix can't access a smalltalk image. if i want windows to access data on unix, then i write it to a filesystem that windows can read. likewise if i want a unix system to access the data inside a smalltalk image i need to write it from smalltalk to outside the image onto a unix filesystem. it's all a matter of how you look at it.
- mpweiher 5y ago
  It's not a symmetric situation as these are not at the same level of the stack. Unix, as an OS, can and, maybe more importantly, does host a plethora of languages and even operating systems (as VMs). Smalltalk does not, and if you take the OS = language idea seriously, cannot. So Ruby can read Unix directories and files. Ruby cannot read Smalltalk "directories" (the Smalltalk dictionary) or files (objects). And Smalltalk cannot read Ruby objects. Python can read Unix directories and files. Python cannot read Smalltalk directories or files. And Smalltalk cannot read Python objects. Java can read Unix directories and files. Java cannot read Smalltalk directories or files. And Smalltalk cannot read Java objects. etc. All of these can interoperate fairly trivially (though possibly not particularly well) via the filesystem. They cannot (and could not, without significant effort) interoperate via Smalltalk.
  - em-bee 5y ago
    yes, i see your point. interaction of different system at the object level has been done before though and i think that is an area that could use more research and evolution to become usable.
    - mpweiher 5y ago
      > interaction of different system at the object level has been done before though Yes. I have used this (CocoaJava, Tcl/ObjC, Ruby/ObjC, etc.) and also implemented it myself (Squeak/Objective-C, among others). Even though I'd say that Objective-C is probably about as good at this as it gets, the end results are still complicated and fragile. In the end, what ends up most workable is that one object model is declared "it", and the rest of the languages then just skins on top of that object model. (See the various .NET languages and reimplementations, JVM languages and reimplementations, and now Truffle/Graal).

msla 5y ago

> How do systems outside of Unix get access to the file system? What is the Smalltalk equivalent to NFS?

tonyg 5y ago
If Smalltalk is pretending to be Unix, it could just speak NFS I suppose. Or use HTTP. Or 9P. Certainly there are classes in most images that model file systems. But thinking of Smalltalk as its own thing, and coming at the angle of interoperation between systems across networks at a higher level than chunks of untyped binary data, there are a few contenders: there have been various distributed Actor implementations. CORBA was available, back when that was relevant. Craig Latta has been doing some wonderful crazy things with interoperation between separate images (e.g. Context, nee Spoon: http://netjam.org/context/ http://netjam.org/context/).
- smackeyacky 5y ago
  Ugh CORBA. It was more of a hindrance than a help when it came to interoperability.
  - pjmlp 5y ago
    Now it is back as gRPC.
pjmlp 5y ago
Xerox PARC own networking protocols https://en.m.wikipedia.org/wiki/Xerox_Star https://en.m.wikipedia.org/wiki/Xerox_Star