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.
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.
> 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).
i think there are three kinds of object level interaction. one is skins where the application is written in a different language than the VM it runs on top of.
the second is some form of object-message passing where two independent applications written in different languages (or also the same language) are able to pass objects back and forth. those objects need not be native objects to either language.
in the third the objects being passed are still connected to the source and calling a method on the object gets sent back to the application it originates from.
i believe CORBA falls into that category.
the one system that i am most familiar with here is bridging pike with php or java and it too is only used one-way in that there are clients written in php, java and pike, but the server is in pike only.
i am mostly interested in the second and third type.
the first type doesn't allow me to write truly native applications because in the end even of i use eg. Clojure, i am still creating and using a java application.
the second type allows me to transport rich data objects, and i see the goal here as replacing the currently text based filesystem with such objects.
one issue is how to transport the objects. xml and json have been used a lot for the second type, but both are to limited.
we need better object formats and interfaces and filesystems that support them.
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.