In fact, you can get C-level performance with Smalltalk levels of encapsulation and dynamicism if you pay just a little attention. See iOS and macOS Performance Tuning: Cocoa, Cocoa Touch, Objective-C, and Swift: https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...
Also, if I understand Smalltalk correctly, the full Smalltalk environment includes substantial runtime services which require a Smalltalk system to "own" everything, so while a C program could host a Smalltalk system and a Smalltalk system could call-out into C code, a Smalltalk system can't support things like C function exports or allow other code to arbitrarily call-in and out of Smalltalk, unlike how other object-management systems like COM, DCOM, and CORBA work. I suppose the problem is similar to getting .NET code to interop nicely with a legacy C++ codebase: a native program can host the CLR, and a CLR-based program can P/Invoke into native DLLs, but due to the requisite steps to set-up an AppDomain (and deal with now-obsolete things like code-access-security) means that it's non-trivial, if not possible, for native code to arbitrarily call-in to CLR code and vice-versa.
allow other code to arbitrarily call-in and out of Smalltalk
why not? isn't that the property of any RPC interface? can't RPC be completely language agnostic? as far as i understand this all depends on how flexible the RPC interface is.
i have certainly seen RPC interfaces in high level languages that allow me to call any object or function in the target system. in fact, i am working with a platform written in pike that has such an interface. pike is a high level language like python or smalltalk, and the RPC interface of this platform has clients in java and php where i can access server side objects as if they were part of the client. like i could with CORBA or others.
there is no reason why smalltalk could not support something similar.
CORBA and DCOM both expose an endpoint to allow remote systems to access a specific remote environment. You could run two or more distinct CORBA or DCOM environments on a single remote host (which may or may not use the “same” objects, e.g. singletons). Even with a single remote environment you still need to set it up (COM+ MMC snap-in, anyone?), and the problem with having a setup process is the point of my comment: calling from arbitrary program into a Smalltalk program requires that Smalltalk environment to already exist somewhere - or for that entry point you’re calling-into to be responsible for setting-up and tearing-down that environment when it returns. Stuff like this is both context-sensitive and non-trivial.
For example, assuming that multiple entrypoints can share a lazily-initialised singleton environment then how should concurrent calls into the environment be handled? What about asynchronous callbacks? And so on.
Or more generally: “How can Smalltalk be integrated into an existing - or new - non-Smalltalk system?” - and it seems to me the answer is “it’s complicated” and not as simple as invoking a thread-safe C-style export that’s automatically generated by the Smalltalk toolchain.
i think there are two concepts being mixed here, and i am not quite sure how you relate the two:
if i understand you correctly then you seem to suggest that embedding smalltalk into a c environment is not trivial because smalltalk has its own runtime.
that is something that i agree with. but here is my confusion: how is that different from CORBA? doesn't that also just allow connecting two distributed runtime systems?
so my understanding is that it would be possible to have a c<->smalltalk bridge just like CORBA, (and that's the same kind of bridge in the pike based platform i mentioned between java/php<->pike) but both are different from embedding smalltalk outright.
all that said, from what i understand objective-smalltalk is something different entirely, it is a smalltalk environment with an objective-c based runtime, more like clojure or other languages on top of java.
Also, the "Object Templates" block is misconfigured.