Microsoft Research's C-Omega

Microsoft Research has produced a data-oriented programming language by merging C#, XPath and SQL. O'Reilly's XML.com website the inside scoop on the language in the article titled Introducing C-Omega written by Dare Obasanjo.

Comments

Grammar, please

[straybullets]

I understand this is very important news and that not a second should be wasted before disclosing to the world, but still you need to use the verb website correctly and say :

O'Reilly's XML.com websites the inside scoop on the language in the article titled Introducing C-Omega written by Dare Obasanjo.

Re:Merging C# and SQL?

[hey!]

Not only is there nothing wrong with it, it's quite nice not having to generate lots of boilerplate code to fetch a value from the database. Combine this with iterators and collection objects, and it could be very nice.

Of course, the main issue becomes portability, but portability is not a top priority for everyone. In any case it is very possible to write non-portable code without embedded SQL and quite possible to write portable code with embedded SQL. For example you could embed your queries in interfaces specifying iterator methods, and have concrete classes for each database platform.

None of this stuff looks particularly radical. Which is a Good Thing (TM). That's what C# is -- nothing creative, just take the proven ideas from other platforms and don't try anything really new like Java did with checked exceptions. That's what Linux is, if you think about it.

Embedded SQL is not a radical new idea -- I remember it from special C preprocessors as far back as the early 80s. The XML features they have look to me like they've rediscovered S-expressions after 40 years, only with uglier (!) and less general syntax.

That said, the combination of XML as a transport/archival medium, object operations, and relational object serialization is very common. Therefore a scripting language which reduces the impedence mismatch between these is also a Good Thing (TM). You might think the XML-ification of everything in sight is the height of stupidity when in many situations superior technologies such as ASN.1 exist. I certainly do. But twenty five years in this business has taught me that what makes sense to you doesn't affect the choices you need to make as much what everybody else in the world thinks.

Not the end

[illuminatedwax]

We still have C-Aleph to go.
--Stephen

Re:data != object

[TuringTest]

XSLT is an example of a data oriented language: you define what to do for every kind of data that can be found in a data flow; you specify how to transform the old data into the new one.

In an object oriented language, you build classes of objects that make series of calls to other objects following a given recipe.

Re:data != object

[zangdesign]

Object Oriented Language = data knows what to do with itself but programmer don't know what to do with the data.

Data Oriented Language = data doesn't know what to do with itself and neither does anyone else.

healthy stuff

[netsfr]

sounds like something I should be ordering from Hi-Health or the local vitamin store.

makes me cringe

[Anonymous Coward]

I read this article when it came out. It made me sad to see this kind of stuff from a group with "Research" in the name (the of course you see the "Microsoft" and you realize this "research" is actually just Microsoft's "buzzword factory").

Let's see the level of discourse here:

unlike prior data interchange formats, XML can easily represent both rigidly structured tabular data (e.g., relational data or serialized objects) and semi-structured data (e.g., office documents).

First of all, "relational data" is like saying "calculus numbers". I assume he means "relation value" when he says "relational data".

Relation values are not tables. A table is a representation of a relation value. Relations represent sets. Both the attributes and the tuples are unordered for instance, it's hard to draw a picture of something that has no intrinsic order.

The relational model is not "rigid", that's the whole point, you can use relational algebra to create arbitrary expressions, and if your constraints are correct, you can derive any correct fact from your database. This author clearly thinks the relational model is just a "bunch of tables" and rejects it without further thought. It would be more correct to say XML uses a rigid tree structure, while relational databases represent any possible data structure.

Serialized objects are not tabular, they are ad-hoc depending on what library you are using. Some libraries use XML. Again he should know this.

Basically it doesn't make sense to group "relational data" with "serialized objects" and call them both "tabular data".

Next is the favorite buzzword of the XML practitioner: "semi-structured". I have no idea what that means. XML documents are streams of UTF-8 (or similar) characters. This is a rigid structure. At the next level of abstraction, they are a tree of nodes. Again, rigid structure. The structure of the tree can be further constrained by schema, but even if it isn't, it's still rigidly structured. How could you parse it, otherwise?

So already we know this "research" is just going to be a misunderstanding of existing data models with some programmer-friendly buzzwords thrown in. As expected: if they truly understood data models, they wouldn't have written this paper or invented this language to begin with!

The former tends to be strongly typed and is typically processed using object-XML mapping technologies, while the latter tends to be untyped and is usually processed using XML technologies like DOM, SAX, and XSLT.

So tabular data is strongly typed and processed with object-XML technologies. Wouldn't it be processed with tabular-XML or tabular-object technology? I've used tabular data (like CSV) and I've never needed objects or XML with it.

In the case of processing strongly typed XML using object-XML mapping technologies, there is the impedance mismatch between programming language objects and XML schema languages like DTDs or W3C XML Schema.

Okay, now I get it.. we're processing strongly typed XML using object-XML mapping technologies. Based on the previous sentences, I think this means strongly-typed XML is actually equivalent to tabular data, right? I guess the author is just confused. I know I am.

And there's another favorite buzzword: impedance mismatch. Usually this means the programming is trying to match up two different concepts without realizing it (like variables to types or values to variables). I think the author here just means "requires awkward syntax".

This is the point where I usually stop reading a paper. But I glanced at the rest. Basically he 1) creates a hierachical, application-specific database. Both of these concepts were rejected decades ago. And 2) he shows a language which is basically the same as existing languages except you don't need to put your XML and SQL in double-quotes. Okay. This can be valuable. But he uses something that looks like SQL, rather than relational algebr