Some other ‘softies blogging OOPSLA:

• Keith Short talks about the DSL Tutorial and apologizes for our keynote demo.
• Steve Cook talks about the MDA panel and says the keynote demo “wasn’t such a great idea”
• Stuart Kent describes the DSL Toolkit and calls the keynote demo a “commercial break”
• Michael Lehman briefly describes his work building a software factory for the DSL Tutorial and blogs Jack’s GPCE keynote presentation on Software Factories

Finally, Brant Carter took me to task for pointing out that Alan Kay ended his Turing Lecture with a product demo. Brant makes good points and I agree with all him. I think all the ‘softies blogging OOPSLA have acknowledged how poorly this went and I certainly didn’t mean to imply that somehow we were vindicated by Alan’s demoing stuff in his lecture. I plan on giving Squeak a deep look when I get some free time – I have an 18 month old son so Alan’s lecture on teaching computer science resonated with me.

Last night, after the Turing Lecture, we hosted a FlashBoF on “DSL’s in Visual Studio”. Stuart answered a bunch of questions and gave a much more detailed demonstration of the new DSL Toolkit than we could show during the keynote. Here’s what I learned from the session:

• Models are stored in XML files. The language designer outputs an object model and will eventually also output an XSD. For example, here’s a screenshot of the language designer from the DSL Toolkit we’re releasing. Inside the designer, I’ve got a sample UIP DSL (I hacked this up on my own, this is not exactly the same one we demoed yesterday). As you can see, there’s a PageCollection concept which contains Page concepts that have Name and Kind values. Page concepts also has a collection of Transfer concepts, which in turn have Label values. Generating an object model makes it easier to write tools that manipulate models. Typically, I’m anti-XML-Serialization but in this case – where we have a relative simple XSD – it works fine. I could also manipulate the model by accessing the underlying XML if I want to.
• Code generation uses templates and looks a lot like CodeSmith or old-school ASP. You interleave the static elements of the generated code with blocks of code that access the model (via the object model described above) and generate the dynamic model-specific elements of the code. So I’m guessing that people using the codegen tools like CodeSmith will feel right at home with this toolkit.
• In the current builds (which is to say later than the build that we’re releasing first – the first build doesn’t include any of the code generation support) we’re generating a single code file from a model. Eventually we’ll be able to manipulate multiple files from a single model. This is similar to how the Class Diagram works – add a new class onto the diagram and a new file gets added to the project, delete the class from the diagram and the file gets removed from the solution.
• Not all models are used to generate code. For example, in VSTS the Logical Data Center and Virtual Deployment models don’t generate code. They are useful  because I can use them to validate the Distributed System Model which does generate code.
• Someone asked about the implications of code coverage, profiling and test-driven development on a DSL-based process. Frankly, I don’t know but it certainly got me thinking. The general consensus was that we’re still in the bootstrap phase of making DSL-based development a reality and these are issues we’ll have to deal with as we move forward.

We interupt this blog’s coverage of OOPSLA with a quick observation & question related to development…

I’m hacking around writing a Word 2003 SmartTag in C# (more on the why later). I wanted my recognizer to be document-dependent – i.e. depending on some custom document properties, I wanted to change what gets recognized. A little digging reveils that there is no way (that I could find) to access the Word object model from the recognizer! The Recognize (and Recognize2) method receives strings as parameters, but it doesn’t receive an app-specific target object. This is unlike the Smart Tag Action‘s InvokeVerb (and InvokeVerb2) method which receives a Range object (from which you can navigate to the containing document, application and window) when running inside of Word. Bummer.

I think the reason for this is that the recognizer appears to run on a background thread while the action appears to run on the main app thread. Furthermore, both threads are STA apartment threaded, so if I can access the COM-based object model from the action thread, I can’t access it directly from the recognizer thread. I actually hacked up an add-in to provide the ActiveDocument to the recognizer thru a backchannel and it hangs Word on shutdown. I thought there might be an issue releasing the COM reference, but explicitly releasing it crashes the recognizer the next time it accesses the ActiveDocument.

So I’ve come to the conclusion that I somehow need to marshal this call from the background thread to the main app thread the action and addin are runing on (I did verify that both of those run on the same thread). The question is, what’s the best way to do that given that I’m writing this in C#? I thought I might use a system similar to Windows Form’s Control.Invoke(…), but it turns out that works by sending windows messages which isn’t particularly feasible for my problem. So now I’m thinking I have pass the ActiveDocument reference to the background thread using CoMarshalInterface. Or I might be able to use RemotingServices.Marshal() instead.

Anyone have any ideas? If so, leave a comment or drop me a line.

This morning was Rick Rashid’s keynote with “the big announcement“: a framework and tools for developing Domain Specific Languages in VSTS. Essentially, this is a toolkit for building your own modeling tools on top of the infrastructure that powers the VSTS Distributed System Designers (aka WhiteHorse). Personally, I think this is pretty exciting stuff and I can’t wait to play with it more in the coming months.

As part of the announcement, they demoed the toolkit with a DSL for programming the flow of pages in a web application. Typically, you would use a framework like User Interface Process for this. However, the UIP comes with 130 pages of documentation and a variety of classes and configuration settings. By building a DSL on top of the framework, we can make the developers significantly more productive. I’ve posted a screen shot of the designer – it’s essentially a box-and-stick modeling environment – boxes are pages and sticks are transitions. Dragging a new page onto the design surface from the toolbar generates a new web page in the solution. Dragging a transition onto the design surface changes the config file. That’s much more productive than mucking around in source and config files to accomplish the same task.

Of course, the standard question when we announce stuff like this is “when can I get my hands on it?” We’re going to release a tech preview version of the DSL Toolkit “real soon now”. You’ll be able to download it from the newly minted VSTS Workshop page. I hear that this project, now that it’s public, is going to be very transparent to the community, so keep an eye out for more info (of course, I’ll blog it when the toolkit is released). Honestly, the version we’re shipping “real soon” is much rougher than what we previewed in the keynote this morning, but we’ll be updating it periodically as it marches towards release.

I’ve had several good conversations in the booth with people wanting more info about VSTS and the DSL toolkit as well as Software Factories in general. As is typical, I learn as much as I teach in these sorts of discussions. For example, I met Gan Deng from Vanderbilt who showed me GME – the Generic Modeling Environment – which is DSL modeling environment similar conceptually to what we announced today for VSTS. Not sure when I’m going to get to play with it, but it’s nice to see academia support for DSLs.

The only downer is that some of the OOPSLA crowd was put-off by a product demo during the keynote. Stuart described it as a “commercial break”. Several people gave me “brutal feedback” that brazen marketing displays like product demos don’t work in OOPSLA keynotes. But others thought it was cool. Good to keep in mind for next year.

Update: Alan Kay, in his Turing Award Lecture, made a joke about about our product announcement this morning and everyone laughed, including me.

Update 2: After making a joke about our morning’s product demo (and several other assorted jabs), Alan Kay ended his Turing Award Lecture with…wait for it…a product demo. Two product demos, actually. Squeak is educational programming environment, based on Smalltalk. It is freely downloadable and has an associated community and wiki. Alan did a simple little demo where he drew a car and a steering wheel and was able to steer the car as it moved by rotating the steering wheel. Cool. Alan’s other demo, Croquet is a “massively multi-user virtual learning environment” which is built on top of Squeak. While I liked Squeak, I don’t know many people who spend significant time in a virtual 3D space who aren’t gaming. Frankly, Croquet doesn’t seem particularly practical or useful – check out this screenshot of document collaboration in Croquet. In this example, the 3D space is more of a distraction than an enabler. The only place Croquet seems useful to me is for dynamic 3D simulations, such as this screenshot demonstrating the Coriolis effect.