This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: ObjectStudio Futures
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.
This is being given by Helge Nowak, our German tech sales rep - which means I can take notes instead of being up in the front of the room :). ObjectStudio is an important piece of Cincom Smalltalk - while VW gets most of the (verbal) attention, OST is used quite a bit in Europe - particularly in German speaking Europe. What we are looking for here is direct feedback from our customers as to where we should be heading with the product - there are a couple of possible routes forward on the VM level.
First off, why are we at something of a crossroads at the VM level? OST has a byte code interpreter, not a JIT. That means that relative to other Smalltalk implementations, it's execution can be slow for certain CPU intensive operations. We have a fast, cross platform (including Windows) execution already - the VW VM. However, OST is a Windows specific product which ties fairly tightly to things like the Windows GUI and COM components. So, that puts the MS CLR (the engine used by the various .NET languages) out there as something we need to investigate.
What have we learned about from our OST customers?
Future Proof
Faster access to new stuff
XML
Web
Web Services
Better GUI
Better DB connectivity
Faster execution
We are addressing a lot of that already - by bringing Opentalk to OST, we have connectivity and interop with VW, and the stack of services it supports. We have improved execution speed over the last two releases, and made a number of improvements to the COM framework. So that leaves us with a discussion that we need to have both internally and externally: do we take a serious look at the CLR, or do we extend and enhance the existing VW execution engine to support the things OST needs (Native Windows widgets and full COM support, for instance). This would be of interest to both OST and VW customers - it would extend OST services to VW users - and there are plenty of them that VW users would be happy with (Native Widgets, full COM Support). Of course, OSt users would benefit as well - much faster execution and (better) access to the stack of VW services.
One of the primary issues in front of us is customer impact. Either change will result in some level of migration effort for end users of OST - we would like to minimize that impact as much as is possible. With that in mind, let's look at both options:
ObjectStudio for .NET?
Get rid of the OST VM and move to the CLR
OST running on the CLR and inside the .NET framework
Smalltalk objects fully interoperating with .NET objects
This would mean an OST VM layer glommed on top of the CLR. It's an interesting question as to how big that layer would be - it all depends on how many services can simply be handed off to the CLR. Why would we want to go this way?
Possibly better VM performance
MS' stated direction for Windows based development
Better UI look/feel (i.e., new widgets - that would mean a re-write of what we have)
New, standard DB support
Interaction with the (large) universe of .NET objects
What problems would we have?
The CLR is clearly designed with static languages (like C#) in mind. See this post for my expanded thoughts on that.as well as Patrick Logan's thoughts here.
The possible solution to that is Whidbey, which is a long term plan on their part to get to better support for dynamic language features. Sadly, it looks like a lot of where they are going is not going to give us much of what we need. For instance, the CLR lacks support for these kinds of things - i.e., we would have to glom these into our own layer:
No interactive mods to the system
No save/restore of an image
No senders/implementors (existing VS support assumes files, not an image)
No way to find all instances
No way to find all references to an object
No way to do #become:
No way to change the class of an object
No way to change the superclass of a class
Whidbey would be the first reasonable CLR to start with (and it's a ways out). The MS roadmap is not completely clear to us on this. What it amounts to is this - we would have to create our own dynamic layer on top of the CLR, and that would be a non-trivial task. In the process, we would lose some of what makes Smalltalk... Smalltalk. Additionally, some of the migration (on the part of customers) would be onerous - existing GUIs would need to be redone. If we could get there, the end result would likely be good for customers (with the above caveats). The problem is, it might be a good ways out - due to the current lack of support in the CLR. And before someone else brings up Iron Python again, note carefully what Patrick said about it.
What about OST/VW co-habitation?
This would mean OST uses the VW VM (with changes made by us in both directions as required). It would not mean sacrificing existing OST services - these (GUI, COM, etc) would move to the VW VM. The end result would be that VW code and OST code would be (mostly) portable between the two systems - potentially opening up the entire VW stack to OST users. Again, we would build an OST compatibility layer on top of the VW VM. The difference here is, all the engineering effort (and code) would be accessible to us, so changes could be made on either end.
In either case - VW VM or CLR - we really can't deliver an interim release. Either the migration will be done or not; once the decision is made, we'll be going in that direction until a final release is ready to be used. The biggest benefit: We can make this work exactly like the current ObjectStudio product. The caveat there is that going all the way there may limit our ability to make use of extant VW tools in VW. On the other hand, there may well be migration effort (the level would vary) if we made use of the existing VW tools.
How does this match cuctomer needs?
State of the art VM
Faster access to new technology
Faster execution
Better GUI
Better integration into (new) MS technologies, but less seamless (than a .NET direction)
Better tools
Support for Linux (and other platforms) - with migration effort
To get to ObjectStudio .NET - it's a radical approach. It's also highly dependent on Microsoft's direction and delivery schedule. It's also the case that we would need access to outside knowledge (i.e., raising the expense of doing this). Translation to you - it would take longer. What about using VW - all the knowledge is in house, and the delivery would be under our control.
This is the point where we need help from the ObjectStudio community. We want - and need - your feedback.
Previous Topic
