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.
Someone's question...
"...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.
3 comments:
Not sure what you mean by the "baggage in all the specific object model stuff". One of the key strengths of the CLR is access to the libraries that ship with it.
There are a number of folks on the CLR team whose mandate is to make the CLR a friendlier environment for dynamic languages. A couple of examples: In V2 there's the new LCG (lightweight code gen) feature that lets the GC collect code fragments that were generated via an eval() style construct. A second example: Jim Huginin was hired this past August to write a native implementation of Python for the CLR based on his initial success with IronPython.
Writing libraries is the hard part, IMHO. The CLR team is dwarfed by other teams that write the frameworks and the tooling that goes along with it.
-John
http://www.iunknown.com
I should have mentioned that I foresee in the future that how & where code gets executed will automatically change as the code matures being more frequently used and reused. As I mentioned on James Robertson's blog in Oct:
And what's wrong with a Smalltalk coprocessor?? ;-)
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.
The most popular publicly shared classes on the STORE/Squeak Map go into the class library.
The most popular class libraries get put in the VM.
The most used classes in the VM get put into the field gate array.
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.
Like the VM though, the developer can create interpreted source level classes that override anything further down, which may replace anything further down in subsequent iterations.
Not changing the language syntax, just where it is executed and the package with which it is distributed.
The Cincom Smalltalk VM does sound interesting. But frankly,, only *really* interesting if it was open source. I am 100% certain that Python on the Cincom VM won't go anywhere if that's not the case -- imagining that all the necessary work happens, and it's feature-compatible with some version of Python, and all that. It might interest a few people, there would be a little buzz, early adopters might play around with it, but it wouldn't go anywhere, maintenance would falter, and the project would die. The curiosity that fuels that kind of thing isn't the same as the motivation that keeps a project going, and that motivation is only held by people that can do practical things, and given the Python culture and open source culture, practical things won't happen if the VM is frozen and has licensing issues.
That said, it could be really cool if the Cincom VM was open source, because it's a VM that is really intended for late-bound dynamic languages. It could become a viable general-purpose runtime environment very quickly; it has the basic technical foundations, but this would add a great deal to its social, economic, and strategic value.
Post a Comment