This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: .NET and multi-language capabilities
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
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...
Previous Topic
