COmega (otherwise known as Cw since most people don’t have an omega key on their keyboard) is on a long list of stuff for me to look at. But instead of actually coding with it, so far I can just read Steve Maine’s blog. He’s got interesting posts on syncronization and streams, the two big features of Cw over C# (come to think of it, we use the “#” symbol as most people don’t have an actual sharp key on their keyboard). I also learned from Steve that Cw comes with basic VS integration – you get project support, syntax highlighting and some Intellisense. Now I just need a few extra hours in the day.

I like Jeff’s suggestions for a Service Oriented Lanugage as well as RebelGeekz’ idea of how to include XML Infoset information in a language without resorting to angle brackets. I wonder what a community developed lanugauge would look like? I’ve experimented with Coco/R which really reduces the effort it takes to build a parser. Of course, the language design and code generation are the hard parts!

Source for Coco/R is available on the Rotor Community Projects page. Other cool projects include a port of Rotor to WinCE, two different AOP projects – one for C# and the other language neutral and a set of improved collections.

Christmas was crazy (my wife’s blog has the details), so I didn’t get a chance to blog about Sean & Scott’s desire for unification of objects and data, Erik Meijer’stwopapers on the topic, or Dare’s responses to both. Programming language evolution is something I’ve keenly interested in. When I first started this blog almost a year ago, one of my early posts was about a disruptive programming language technologies presentation from MS Research. Among the areas mentioned for improvement: were database integration and XML manipulation. Sounds like the Xen language demoed @ XML 2003 is a step in that direction.

When you read Erik’s papers, you’ll notice that one of the goals is to natively integrate XML into the language. He writes: “In our approach XML documents or document fragments become first class citizens.” What’s interesting about that is that if you take XML to mean pure-infoset-data (as opposed to angle-bracket-serialization-format) then you can argue that Data (with a capital D) is not a first class citizen of today’s Object-Oriented languages. Given that a lot of OO code has been written to manipulate data, having a language that explicitly distinguished between the two could be valuable (assuming it made the programming easier and the programmer more productive).

Note, this is the opposite approach from tools like O/R mappers and XSD.exe which attempt to hide the differences from the programmer. We’ve seen a similar evolution in the way we think about invoking objects across the network. Tools like DCOM and .NET Remoting attempt to hide the RPC and make it appear as a local call. But as the thinking evolves, tools like Indigo is designed to make the boundaries across apps and machines explicit. Initial thoughts on data access were to make it all look like objects (i.e. O/R mapping). But as the thinking evolves, maybe we need to make the boundaries between objects and data explicit (and easy) as well.