Updates: From comments...
"for any reasonable success, you need to interoperate intimately with .NET (or Java if you like)"This will come as a complete surprise to all the Perl, Python, Lisp, Smalltalk, and other developers who have been achieving "reasonable success" very well without such capabilities. Better get a memo to them soon.
"Just put a Smalltalk coprocessor on a removable PC card, add a field gate array processor and upgrade it twice a year. Get the extra registers Smalltalk has been craving that Intel doesn't have. With today's competitive chip manufacturing processes, it's within reach.Not sure the future success of Smalltalk should ride on convincing PC owners everywhere to put a co-processor into their boxes, no matter how cheap it may be.
The most popular class libraries get put in the VM.
The most used classes in the VM get put into the field gate array."
First of all, this suggestion seems to ignore the reality that Smalltalk execution is very efficient on the processors those PC owners already have in their boxes.
Second of all, putting classes into the VM, not to mention onto hardware, is not a very smart decision. Read a little about the history of Lisp and Smalltalk then look at the CLR for potential improvements that could be made *there*.
"The most used classes in the field gate array get (automatically) submitted to a company that balances cost, demand, distribution, and chip limits to create a run of these PC cards."Sorry. You flipped the bozo bit.
End of Updates.
"...Why run Smalltalk on .Net? Seriously, I just don't get it...why would you want to?..."
In a comment on James Robertson's blog, Socinian answers the question...
Access to unique device hardware, network security, code/data security, active directory access, etc. Managed code, because eventually, more than one machine will be executing/managing it. Also connecting to 3rd party applications. You can't just compile/link, DLL call, API function call, or SOAP any more.I agree with the vision. The current implementation of dotnet, plus the baggage in all the specific object model stuff, etc. would not lead me to believe this is the vision for that runtime model, however. (N.B. I have been wrong before.)
You have to look where things are going. Cell CPU's, programmable appliances, utility computing, virtual OS, and large cluster computing. Do you want to rewrite a new VM for each of these and what's ever next? Let someone else do the work, so you can focus on a productive application. It's easy to get stuck in a one CPU perspective of the world. Unfortunately, this will change the way applications are created, used, and migrated, as surely as cell phones changed the time and place that we communicate over distance.
I would consider Erlang/OTP, Gambit Scheme, Cincom (VW) Smalltalk as better starting places (among several others), for inspiration if not implementation in support of this vision. Note that Gambit Scheme has hosted Erlang in a prototype that appears to be roughly equivalent in scalability. Note that the Cincom Smalltalk VM appears to be scalable for web systems and capable of running Python a good bit faster than CPython. So I am nominating them as candidates for hosting multiple languages on multiple platforms in support of the dynamic vision above. And with a fair bit less overhead than is apparent in the dotnet runtime as per its own definition.
Just a guess, but with some evidence.