.NET and multi-language capabilities
One of the things we have been looking at is re-hosting ObjectStudio onto .NET. This is research at present - we have not committed to such a project! As it happens, I'm writing this while I'm on my way to the User's Conference in Frankfurt - and I ran across Larry O'Brien's latest article in SDTimes. He's talking about "little languages" (what most people call Domain Specific Languages, I think) - and in the midst of that, says the following:
A fundamental premise of .NET is that a platform that is explicitly designed to support multiple languages and programming approaches is superior to a platform, notably Java, whose design is dominated by the needs of a single language. I am convinced that Microsoft is sincere in trying to give the .NET managed platform as much flexibility as possible, albeit for the purely mercenary purpose of being in a position to explout advances as they enter the mainstream
Hmm. That explains why VB didn't change at all once it morphed into VB.Net, right? ,NET supports any language, so long as it ultimately behaves a lot like C#. Going back to our ObjectStudio plans - we've taken a good initial look at the platform, and our engineers have found a number of issues - any Smalltalk built on top of .NET is going to have to make a lot of compromises, because there are a lot of things you can't do:
- Interactively modify the system
- save and restore an image
- swap object identity (#become:)
- change the class of an object
- change the superclass of a class
Some of those might seem like things you wouldn't 'normall' need - say, changing the class of an object. On the other hand, have a look here, at one of my posts on BOSS Schema migration. BOSS is the VisualWorks object serialization framework; schema migration involves changing the class of an object as you get it back from disk. Would you have to implement a framework that way? Clearly not, or else Java wouldn't support serialization. On the other hand, it's how it was done in VW, because it was pretty easy. Some of the other problems get right into the guts of typical Smalltalk operations, like interactively modifying a system (any time an end user applies an update to BottomFeeder, for instance, that happens).
Ultimately, .NET only looks like it supports multiple languages and paradigms from the narrow perspective of the C language family - many things we take for granted in Smalltalk are simply inconceivable to those guys. if you can't imagine it, you don't even know that it's missing. Now, I'm sure that one could build a middle layer over the top of the .NET runtime to deal with these issues - but it would be hard, and the resulting system would be slows. Supposedly, many of these issues will be addressed now that the iron Python guy is working for Microsoft. We'll see...
Comments
.NET supports any language, so long as it ultimately behaves a lot like C#
[Alex] December 6, 2004 8:51:06.472
See:
.NET Languages
Certainly Functional languages like Scheme and ML (SML and OCaml) do not fit your claim. Is Python C like? Is Prolog and Mercury C like? Forth is very C like?
Maybe you just mean that it is difficult for Cincom engineers to put Smalltalk on .NET? (John Brant has made some headway as has Robowiz.)
MS's sincerity
[Larry O'Brien] December 6, 2004 12:50:47.796
There's no question that the 1.x releases of the CLR were more focused on the needs of C# than any other language. But what I'm convinced of, by talking to people like Brad Merrill and Jim Hugunin ("the IronPython guy"), is that Microsoft is sincere in their desire to make the platform more appealing to other languages. I'd urge you to get in touch with these guys -- they really are asking what changes people would like to see. IronPython's capabilities are a _long_ way from the capabilities of Smalltalk's image and object model.
Having said all that, I would imagine that Smalltalk _would_ require layering on top of the CLS and the CTS: I don't think you're going to get Smalltalk-like behavior out of the "standard" type model. And, while it would be hard (but how much harder than porting to any new platform?), I would imagine that it's an open question as to whether it would be inherently slow. Hugunin thought the same thing with Python -- he started the project in order to demonstrate how inherently poor .NET was and found that it performed well for him. Maybe the same would be true of Smalltalk?
Cheers, Larry O'Brien
MS's sincerity
[Larry O'Brien] December 6, 2004 12:55:55.841
There's no question that the 1.x releases of the CLR were more focused on the needs of C# than any other language. But what I'm convinced of, by talking to people like Brad Merrill and Jim Hugunin ("the IronPython guy"), is that Microsoft is sincere in their desire to make the platform more appealing to other languages. I'd urge you to get in touch with these guys -- they really are asking what changes people would like to see. IronPython's capabilities are a _long_ way from the capabilities of Smalltalk's image and object model.
Having said all that, I would imagine that Smalltalk _would_ require layering on top of the CLS and the CTS: I don't think you're going to get Smalltalk-like behavior out of the "standard" type model. And, while it would be hard (but how much harder than porting to any new platform?), I would imagine that it's an open question as to whether it would be inherently slow. Hugunin thought the same thing with Python -- he started the project in order to demonstrate how inherently poor .NET was and found that it performed well for him. Maybe the same would be true of Smalltalk?
Cheers -- Larry
P.S. "Little languages" are a subset of "Domain-Specific Languages": DSLs that can be mastered in a day or two and implemented in a matter of days or short weeks.
.NET and multi-language capabilities
[ Socinian] December 6, 2004 18:21:54.404
Comment by Socinian
"like Scheme and ML (SML and OCaml) do not fit your claim. Is Python C like?"
Alex: Actually those languages made some compromises to get into CLR .NET just like VB did. Check the compatibility specs.
I once read on the Microsoft Research site that CLR 2.0 was targeted for dynamic languages. They had to cut features to get CLR 1.0 out the door.
The 1000 lb. gorilla will sit down here... eventually.
.NET and multi-language capabilities
[Alex] December 6, 2004 21:12:52.445
Actually you would be hard pressed to find significant compromise in F# - the .NET implementation of CAML
Similarly Common Larceny is a full implementation of Scheme.
So I cannot quite buy your comments.
BTW, John Brant (of Refactoring Browser and #Smalltalk fame) does not see huge hurdles. A view similar to Jum Hugunin -- "... I found the CLR to be an excellent target for the highly dynamic Python language.."
Dynamic Languages on Dotnet
[Patrick Logan] December 6, 2004 23:18:06.033
"Python -- he started the project in order to demonstrate how inherently poor .NET was and found that it performed well for him"
At this point though "perform well" means run about the speed of CPython, which is fairly slow. I would bet Microsoft could make that go faster over time, and will. At the same time there is concern about the overall runtime of Dotnet. It's on the order of huge.
They'll get there, but it is a long row to hoe.
"you would be hard pressed to find significant compromise in F# - the .NET implementation of CAML"
Maybe, I hardly know CAML. Still I think implementations of languages can be largely faithful to their independent definitions. The real problem again is all the baggage that MSFT includes in the Dotnet runtime for little benefit, e.g. the assumed object model and other high level constructs.
Re: MS's Sincerity
[Stephen] December 7, 2004 1:22:53.940
"But what I'm convinced of...is that Microsoft is sincere in their desire to make the platform more appealing to other languages"
Heh...of course Microsoft is sincere! What better way is there to get everyone locked into their platform?
But, the important question here is why? Why run Smalltalk on .Net? Seriously, I just don't get it...why would you want to? Smalltalk has plenty of perfectly good VMs available. Similarly, I've seen the efforts to run Java on a Smalltalk VM, Smalltalk on a Java VM, etc, etc. If I want to run Java, I'm going to run it on a tried and tested common Java VM. If I want to run VB/C#, I'll do it on the .Net CLR.
If you really want tight, fine grained integration, you'd better think long and hard about why you're using multiple languages in the first place. If you only need more of a loose coupling, then run the languages on the VMs they were built for and use one of the many, many communications technologies. Hell, with java you don't even need a separate process, just invoke the jvm dll.
Why run Smalltalk on .Net?
[Alex] December 7, 2004 9:19:31.378
"...Why run Smalltalk on .Net? Seriously, I just don't get it...why would you want to?..."
Smalltalk is amongst the best of development environments. .NET has the largest library and component support, especially for GUIs and business applications. The "why" is so we can have the best of both worlds!
.NET and multi-language capabilities
[ James Robertson] December 7, 2004 19:21:54.546
Comment by James Robertson
Alex,
Bear in mind that you only get the best of both worlds if the VM supports the mechanisms that make Smalltalk what it is. Smalltalk is more than just the simplicity of the syntax - it's also the engine that allows it to run.
.NET and multi-language capabilities
[ Socinian] December 7, 2004 21:10:53.432
Comment by Socinian
"...Why run Smalltalk on .Net? Seriously, I just don't get it...why would you want to?..."
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.
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.