My dad (who needs his own blog) pointed me to a presentation from the 2nd Microsoft Research Rotor Workshop that was held in April in Pisa, Italy. The presentation in question is by Luca Cardelli on the subject of programming language innovation, a topic I’ve blogged on before. I want to take a look at the other speaker’s content, but a couple of things stand out from Luca’s talk.

• Programming Language data has traditionally been triangular, i.e. object graphs, while persistent data has traditionally been rectangular, i.e. database tables. This leads to an integration issue between the programming language and the database. However, data is evolving. XML makes persistent data triangular as well.
• In addition to data evolution, we’re also seeing an evolution of program flow. It’s moving away from threads and RPC and towards schedules and messages. IMO, that’s what Service Oriented Architecture is all about, but Luca’s point is there’s no support in the programming language for this model.
• There’s great coverage of the concept of “semi-structured” data. It’s not an array. It’s not records. It’s “unusual data” in Luca’s terms, which needs unusual programming languages.
• I get the feeling Luca is recommending new languages, not retrofitting existing languages with support for XML data and schedule based program flow.
• Luca points out that type systems for programming languages and for XML are still “deeply incompatible”. This jibes with my last XML entities post. I don’t want different programming styles for internal and external entities. If I can get a programming language that makes it easier to code against XML, that makes exposing internal entities as XML that much more reasonable.

[SourceGear is] announcing a deal with Ximian today. We need Unix clients for SourceGear Vault, but alas, C# has no real cross-platform story. So we’ve agreed to give Ximian a bag of money and they’ve agreed to hack Mono and make it speak .NET XML Web Services to ASP.NET. Vault users will be able to run our command-line client on Linux, speaking to the Vault server, which will continue to be Windows-only.

(Note that we are punting the cross-platform GUI issues for now. The Vault GUI client uses Windows Forms. We’ll tackle non-Windows GUI clients after we get the basic stuff working well.)

It’s easy to feel good about this kind of deal, and not just because it’s an honor to work with Miguel de Icaza. Everybody gets something. Vault users get more flexibility. Ximian gets revenue. All Mono users get interop with .NET XML Web Services. The world is a [slightly] better place.

[Eric.Weblog()]

Very interesting. Initial thoughts:

• Miguel de Icaza does, in fact, rock. But I’ve said that before.
• Apparently, C# does have a cross platform story. C# and CLI is an open standard. Hopefully, Mono’s success will spur others into building production implementations of C# and CLI on still further platforms.
• I’m very surprised that Mono didn’t already have XML web service interop support. It’s true that Web Services support is not part of the ECMA/ISO standard. But then again, neither is ASP.NET, ADO.NET or VB and Mono has implementations of those.
• They aren’t “.NET XML Web Services”, they’re just XML Web Services. There are standards (in progress) for this as well.
• Since Web Services are a supported on many platforms, SourceGear could have built a Unix/Linux specific version of their command-line tool in any language, especially Java which has several Web Service implementations available. But for SourceGear, it appears that staying with C# and CLI was very important. Eric is already on record saying that his company “made a great choice when we decided to build Vault using .NET.” I don’t know how much “a bag of money” is, but I think it’s telling they were willing to pay Ximian to add features to their CLI implementation rather than to rewrite the command-line client in Java and use freely available web service tools.
• I wonder how they will eventually address cross-platform GUI issue. Will they use Mono’s Win32/Wine emulator library or will they rewrite with GTK#?

UPDATE: It was pointed out to me that the term used in the ECMA/ISO spec is CLI, common language infrastructure, not CLR, common language runtime. I’ve updated this post accordingly. Also, this post disappeared for some period of time. Not sure why. But it’s back now.

I’m not the first to report this, but Fry’s is coming to Renton in mid-July (30 minutes from MSFT Campus). That’s Fry’s Electronics, not Fry’s Food & Drug. 😄 Scoble called it the “most important news of the day”. Matt calls it “Heaven”. +1

I moved up from Los Angeles to Seattle about 2 years ago and was shocked there wasn’t a Fry’s anywhere nearby. (I didn’t know about the one Matt mentioned in Oregon). Glad to see this oversight is going to be rectified by next month.

I just got a chance to check out the latest Coding4Fun article on MSDN. The article is about writing macros for VS.NET and one of the examples in the article shows how to build a macro to insert regions into your code by selection. What a great idea! Why didn’t I think of that? 😉

Seriously, thanks Duncan for the link to my region insertion macro and for calling it “much more detailed”. It wouldn’t be without Richard Childress, John St. Clair, Yves Hanoulle and Tim Walters who contributed bug fixes, support for VB.NET and undo contexts.

I upgraded my weblog slightly today. Primarily, I updated my RSS feed to support Timothy Appnel’s RSS Core Profile Draft 2. In addition to mundane changes (pubDate becomes dc:date), I’m finally supporting xhtml:body for my content. Also, a la sTimothy’s sample feed, I’m using a default namespace to finally move all of the RSS elements into a namespace. According to the profile draft, using a default namespace should be considered “optionally permissible”. RSS Bandit handled the updates. Since I’m curious, email me if your reader doesn’t.

I also added support for CDF as per Don’s suggestion last month. It was simple, so I figured what the heck. I did have to search a little to discover that for CDF, the contentType has to be set to “application/x-cdf” in order to get IE to recognize that it’s not just vanilla XML. I had to use Google to find this info, since searching MSDN for “cdf contenttype” came up blank.