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

Just what we needed

[PhilippeT]

Another Language with the precursor C

In other words

[Anonymous Coward]

Microsoft created a frankenstein again which will be an embarrasment for Dr. Billius Gatesus

data != object

[BinLadenMyHero]

What's the difference between data oriented programming language and object oriented one?

Re:data != object

[Josh Booth]

Apparently class data can be accessed as if it was an SQL database. I think.

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.

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:Grammar, please

[blacksway]

I think the real lack here is the missing word 'has' between website and the...

Re:Grammar, please

[Anonymous Coward]

I think the real lack here is the missing word 'has' between website and the...

Really, genious?

Re:Grammar, please

[Anonymous Coward]

Nice one, genius.

Merging C# and SQL?

[Pan T. Hose]

It will be a jack of all trades that everyone hates. Now merged with SQL to make things worse... Please, don't confuse relational algebra, predicate calculus and set theory with procedural algorithm description notation. They are not in the same problem space.

Re:Merging C# and SQL?

[lomov]

People have been coding in embedded SQL or, to the contrary, various kinds of P-SQL all the time. What is wrong with that? Relational algebra, predicate calculus and what-not is all very well, but you have to actually write some code which, like, interacts with user, network, and some such. Last time I checked SQL cannot do that.

Re:Merging C# and SQL?

[Anonymous Coward]

And how would you want SQL to interact with users? "Please return a set of tuples that satisfy those predicates, and by the way, ask the use what's his email, send him a password, then wait for verification, and then show him a shopping cart, and a list of products, and, and... oh, and commit the transaction after a week." Do you even KNOW what a relational model is? Relational algebra, predicate calculus and "what-not" is not "all very well" -- it is essential to understand relational databases. Otherwise you might use the filesystem just as well, and you don't even need a RDBMS. If, OTOH, you want USE a relational database instead of just a fancy data store with SQL frontend, then I'm sorry pal but you HAVE to understand the relational algebra and set theory. See Wikipedia.org/Relational_model for a good start.

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.

Re:Merging C# and SQL?

[lomov]

My point was not that SQL is not needed. My point was that you need things besides SQL to write applications.

Re:Merging C# and SQL?

[lomov]

There are truly innovative features in C-omega (at least for "mainstream" languages, which it apperas to try to become).

The first is treatment of concurrency based on join-calculus.

The second is type system for XML. There is a lot of research in CS for strongly-typed XML processing (check XDuce for one).

TFA actually does a good job of presenting most important concepts of those for people not quite familiar with undelying theory.

Re:Merging C# and SQL?

[Anonymous Coward]

A "type system" for XML? Strongly-typed processing? Has the world gone mad?

XML is a TEXT FILE FORMAT!

God help us.

Re:Merging C# and SQL?

[Anonymous Coward]

It will be a jack of all trades that everyone hates.

Correction, it will be hailed as something new and shiny and coders everywhere will latch on to it.

It's sad. Hierarchical databases were rejected decades ago as not being general enough. They gave way to network databases. Then network databases gave way to relational, because relational is general enough to represent all data structures. Yes, SQL is pretty shitty but it at least it tries.

And application-specific databases were also rejected for not being general enough. What if, you know, you wanted to access the same data from another application?

Here MS has combined both obsolete concepts into one neat glossy package. Wonderful.

Ruby + ActiveRecord + YAML

[Anonymous Coward]

How does it compare with Ruby + ActiveRecord + YAML?

Re:Ruby + ActiveRecord + YAML

[Slime-dogg]

From the code snippets, it looks like they borrowed Ruby's concept of blocks.

def y(x)
yield(x)
end

y(2){|c|
puts c
}

This would just print out "2" to the console, but it works by passing a block into the y function, and y just executes whatever is in that block.

From O'Reilly:

public string* LoTR(){
yield return "The Fellowship of the Ring";
yield return "The Two Towers";
yield return "The Return of the King";
}

public void PrintTrilogyTitles(){
LoTR().{Console.WriteLine(it)};
}

They borrowed the yield statement, and the way of passing blocks into functions is very similar to Ruby.

There really isn't anything new. I hardly use XML for anything at work, and though I do like the idea of passing blocks of code around, this is similar enough to delegates.

Re:Ruby + ActiveRecord + YAML

[Anonymous Coward]

From the code snippets, it looks like they borrowed Ruby's concept of blocks.

Er... you mean Smalltalk's, right?

Ruby fanboys are the one thing on this earth more obnoxious than Perl fanboys. At least the Perl guys don't believe their language invented everything.

Doesn't looks as it would catch on...

[Gopal.V]

Firstly you can't type C easily in normal ascii (unlike C/C++/C#/ etc..)

Eventhough it brings in some syntactic sugar, I suspect that most of it is just that and won't offer any better productivity. Nullable types wrapped into a union like looking thingy , anonymous structs which confuse the user in terms of code clarity.

All in all I'm less than impressed in this evolution of C-like languages. I prefer the path Python (more correctly Parrot) has taken rather than C

Re:Doesn't looks as it would catch on...

[i88i]

All in all I'm less than impressed in this evolution of C-like languages. I prefer the path Python (more correctly Parrot) has taken rather than C

There is actually a language being developed thats attempting to fuse ideas from c-omega & python together, called Spry

No idea if it'll ever be finished, but could be interesting if it works.

Re:Doesn't looks as it would catch on...

[Gopal.V]

Btw, I typed "C ω" everywhere.. too bad it doesn't render even here..

I do have to say one thing about C-omega though, it might be faster as more compilers move this into concurrent code - but as of today I don't see any parallelized execution systems in .NET. Maybe the a multi CPU machine might extract better performance out of threads/whatever the compiler/JIT churns out.

Maybe MS imagines that anything that runs Longhorn will need dual CPU/cores :)

Longhorn and WinFS marketing ploy

[Anonymous Cowherd X]

I for one am not impressed, this is just a marketing ploy to make the public believe that Longhorn and WinFS will be released soon. Just think about it, this new programming language screams WinFS.

WRONG!

[Anonymous Coward]

Microsoft Research != Microsoft.

MSR is nothing more than funded think tanks. Most of what they do never even comes to light.

Its not even being advertised.

Get a clue boy.

Re:WRONG!

[MindStalker]

Yes, but he is right that this programming language screams WinFS. Maybe thats what holding it back, WinFS really is useless unless programs are written to take advantage of it. Personally I wish Microsoft would have built WinFS off a new query language as SQL really needs throwing out but going to hang around simply because its become THE standard. When you are writting entire new systems though, the standards can be changed easier. So the realease of WinFS would be perfect, especially if its backwards compatible to SQL.

omega?

[St. Arbirix]

Isn't a bit lofty of an assumption to assign the last character of the alphabet to a new incarnation of C? As if C-Omega is the culmination of all work before it up to the alpha version of C.

Some times I worry about the effects of megalomania.
"Only through Windows can you reach productivity."

They've already covered "Blessed is he who waits."

Re:omega?

[Anonymous Coward]

Actually, this is just a Microsoft Research mooning of the general geek population. Isn't it amazing that their Omega looks like an ass in the article? Just think of the possibilities on the marketing literature parodies.

This is your C on Crack...

</juniorhighmode>

Re:omega?

[belmolis]

Well, outside of Microsoft the evolution of C has proceeded in a different way, namely to D.

A Language or an API ?

[M1000]

From the examples on the site, that's not a new language, seems to me its just a new API...

Re:A Language or an API ?

[superpulpsicle]

Well in M$ land visual basic is considered a language. Even though it's technically a bloated API on top of regular basic.

And of course.....

[the eric conspiracy]

It requires MS SQL Server 2003.

Not the end

[illuminatedwax]

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

zerg

[Lord Omlette]

Off-topic, but the FPP should have said Carnage4Life instead of Dare Obasanjo...

Computer science

[Anonymous Coward]

What's the difference between a stream and a state machine?

Arrogantly named programming language

[tod_miller]

If they release another 'lets get all developers back to pwn the intarwebnet' language they woudl have to call it:

Visual-omni-ueber-C-sharper-alpha-omega-cognis-J -g yros-++

" C "

As much as I hate them for abusing the Greek language, we have a language which we can say:

"I C-Boobs!" :-)

Have you noticed that googles publicly tagging 'beta' to websites has been caught up by amazon, yahoo, msn, and shedload of others.

People will now think BETA is better than release!

- Beta testers get stuff early
- all of google is basically one big beta...

full circle

[elhoratioco]

In the old days the os, program language and database were united as a mainframe. as400/RPG

Now everything is separated everything out into independent systems/servers. any os, any language, and database server.

With languages like this were moving back again.
Sounds like 1980's CA-Clipper to me.

Either way, the buzz on .NET is fading and MS needs a new technology to keep marketing hype up.

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

Re:makes me cringe

[Anonymous Coward]

You said it better than I could. Thank goodness there are still a few folks around here that understand fundamentals.

Re:makes me cringe

[Anonymous Coward]

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").

And thus you demonstrate that you have no fucking clue. Microsoft Research is a bunch of academics approximately 10,000 times smarter than you are; the "Microsoft" in the name merely indicates the source of their funding. Microsoft the American corporation rarely actually makes any use of their technology.

For example, Simon Peyton Jones (Microsoft Research Ltd., Cambridge, UK) happens to be one of the main voices behind the Haskell standard. Heard of Haskell? You know, the pure lazy functional programming language with foundations in category theory? The one that can express principles so succinctly that real working programs are often mistaken for specifications? Yep, a lot of the research is done with Microsoft's money.

Yet somehow... I don't see Microsoft Visual Haskell appearing in their product lineup. I don't even see Microsoft mentioning FP buzzwords very often. (The only example I can think of is their decision to call the Longhorn shell "Monad".)

Oh, and did I mention that all the Haskell implementations are Free Software in the Stallman sense of the word? Including GHC, that has been worked on heavily by people in Microsoft's pay?

Could it be that Microsoft is actually funding pure academic research into programming with the intent of benefitting mankind as a whole, instead of cynically manipulating the world to further its Evil Plans of Doom?

Yup. It could.

STOP

[Anonymous Coward]

How much crap can you put in a language. Check out Nickle for a much simpler approach to building a language.

Totally wrong!

[BerntB]

Of course, the main issue becomes portability, but portability is not a top priority for everyone.

Now, that is a totally wrong statement about this Microsoft product!

Portability is very important for them -- they put lots of good money and talent into avoiding that terrible problem!

(I wish I could add a ":-)" here, but not being compatible is a standard monopolist tactic. See e.g. file formats.)

"Nullable types" disappointing

[slamb]

I got excited for a second when I saw the "nullable types". I was hoping for a second this was a more radical feature that I saw somewhere (in Cyclone, maybe):

You can say if a reference is "nullable" or not. Nullable references can always be assigned any value; non-nullable references can always be assigned from non-nullable references. When you try to assign a non-nullable reference from a nullable one, there's a runtime check inserted.

In other words, it'd be a safety feature. In a lot of cases, it doesn't make sense to pass null to a method. With this feature, it'd be possible to see from the method signature if that's true. It'd save writing a bunch of assertions for those of us who already are picky about this stuff, and be a hint to others that they should be, too. And those assertions are quite useful - they make the program fail sooner, closer to the code that caused the error.

Instead, this is a feature that just lets you assign null to primitive types. By a completely different mechanism than you use for classes. Boring to me - I like languages where there are no special primitive types. Enhancements to them - especially additional differences to remember - won't get me excited.

Re:"Nullable types" disappointing

[CaptnMArk]

Nullable "primitive"(ish) types could be done in c++ with minimal effort.

Re:"Nullable types" disappointing

[Anonymous Coward]

I think you misunderstood the whole point of nullable types. The idea is more like nonsignalling NaNs. That way you can do a whole operation which may have any number of nulls involved, and if you even care if any of them are null, you simply check the answer. The nullable types don't throw exceptions, meaning you don't have to put checks in all over the place.

aQazaQa

They created...

[Anonymous Coward]

... another Perl?

May god have mercy on their souls.