Gavin Bierman - Microsoft Research in UK works on database query language

Ooo my, they have the UK starting each sentence with "So" also.  Who started that at MS anyway? I think it may have been Jim Allchin (maybe not) Anyway, very nice work and really good ideas.  That SQL stuff seems like low hanging fruit that nobody thought about doing - great stuff.  I think Anders H. is thinking about adding this for 3.0 and maybe other/different data access stuff to the language - we shall see.  Cheers.  

Now that ROCKS!!!  I am a FoxPro Developer who finds dealing with data with ADO.NET to be somewhat of a pain.  This would make life ALOT easier.  I hope to see it in a final product sometime.

~Ant~

Crazy awesome - I would install that preview right now if it didn't need 2003 (all I have is 2002).

So, what's up with the stream type?  Doesn't that totally blow away pointers in unsafe blocks?  Couldn't they just use *type, or type% or type<insert other symbol here>?

maybe that project is somehow (I know they're not working together) related to the stuff Anders Heijlsberg talked about for C#3.0 .. data integration into the language... would be a very nice feature to have, indeed. 
svg Figure() { yield return <svg ........ />; }
my question would be if the return type 'svg' has to be declared somewhere? Or is it just saying 'this is an xml fragment called svg that's produced in this method'? So is 'svg' in this case more than a name, i.e. a type that has properties, methods and events?
very interesting stuff, as always !

Maybe I've been doing database development for too long, but aren't you better off using a stored procedure?  Embedding SQL doesn't make sense for most applications.

Sometimes you need to dynamically generate SQL in the application, but I don't think this solves that problem.

Maybe this will make a lot more sense after I get a good look at Yukon?  I don't see much value for the client or the middle tier, but maybe on the database server itself.

Clearly there's some value in the idea - catching problems at runtime is no fun.

While we are critizing the production of these videos perhaps you could have the cameraperson recommend to the person doing the demonstration to make their code font much larger.  Makes it much easier to read.

I can't see anything with the link provided...

nah, keep the videos simple and quick to produce. i think that the advantage of having a couple of videos a week really outweights an improvement in production quality. i used to catch every episode of the .net show. but one video every month or so doesn't do it.
quick insight into current projects at microsoft - that's what channel9 is all about, imo.

sorry about the lighting chaps, there are some other MSR Cambridge vidoes on the way which are also a little on the dark side :O(

I got a slap from the Scoble for this, since all the MSR videos were recorded on the same day I didn't have any chance to go back and re-record, the good news is that I'm recording some new video this week and will certainly make sure I get the lighting right this time round...

- Mike

I would be interested to know how the "So" thing got started as well. I think "so" is better than saying "uhhhh well...." but really, it's pretty much expected now that if you ask a developer a question, the first word out of their mouth is going to be "So..."

A thing that would have been even better is ORM. Object/Relational mapping. Something like Hibernate (http://www.hibernate.org) for .NET.

This is AWESOME!! I do a lot of database driven apps these days and god how id love to have Cw in C# now. Great job Channel9 Gonna get the download and start playin around with it.

Any one willing to comment on whether this makes it to C# 3.0? I sure hope it does cause it would be a real productivity boost on database driven apps.

To answer some of the questions/points:

1. Why do you say "so" all the time? Didn't know I did. Think it was just nerves...

2. Unsafe code? Cw doesn't support unsafe code. It supports everything else of C# though...

3. What's svg? If you download the compiler then you get this demo. You'll see the file xsvg.cw which contains the declaration for svg. It's a Cw class declaration, but you could read it as a type declaration in xsd etc.

4. Stored procedures? It depends on what you're doing. Cw is really useful for middle-tier apps - you're freed from using the rather weakly-typed ADO.NET libraries. We're currently checking that Cw runs under Whidbey. Assuming that it does, then you'll be able to use Cw to create assemblies that can be called from SQL using SQL Server Yukon. How cool is that?!

5. Bigger fonts. Something weird happened here. Just before Mike pressed record I increased the font size, but VS went wibble. Never seen anything like it - weird colours, bold, etc... Anyhow, Mike was on a tight time schedule, so we just went back to default settings. Sorry if it isn't very readable. All the demos are included with the compiler.

6. This is awesome/it rocks/... Couldn't agree more. Let me go and tell my manager

Gavin.

Cheers Gavin!! Playing with the demo right now... VERY impressed. Keep up the great work!

Gavin, Anders Hejlsberg talked about working on something like this after he's done working on C#.  Is he in any way involved with the Cw project?

Just thinking about something and not sure how it fits with Data access language stuff.  Recently I was doing some Data Tranfer Object stuff using WSE to pass copies of objects (or simple versions of them) from server to client and back.  This gets really hairy, real quick when more then a couple data structures and forget about changes on the server objects.  I am wondering if all your server objects be expressed using SQL so you can transact against them like a DB.  So you don't need to create the DTOs, they just happen under the covers.  Updates and transactions would work same way.  Changes to the server objects would just happen and you will get compile error on client via compile time check if propery missing, etc.

Also wonder how this would fit with Indigo, if Indigo already does this or how Data access may further leverage Indigo to pull this off seemlessly.  Passing ADO tables is not the answer either imho.  Just curious what the thought are about push/pull DTOs in regards to this stuff.  TIA

That's pretty cool. I wonder when that stuff will get put into C#, and eventually VB.NET.


I have one question about the Preview of Comega. How reliable is it to use for a commercial/release quality application? Do we really need to worry about compiler bugs?

well my initial reactions were:

1) o - hmmm - ummm
2) I use stored procs. I use them because I like the interface seperation between by procedural code and my database

and then something clicked.....


Where could i use this language... in SQL Server itself.

Yeah I know SQL 05 will host c# .net (primarily because Oracle host Java). But, if i was to be honest, 10-20% of my stored procs are really application code rather than data access and this forn of hybrid expressive language could be awesome in those situations.

wow, cool. i love it, would have sooo much use for it, especially with our developers who make mistakes in SQL all the time. Oh, and another thing, that will help with SQL Injection attacks! I hope this gets into VS and C#.

However, i remember reading article about SQLJ years ago... exactly same thing. I understand that Cw is more than that, but still.

IMHO...

One thing that is needed in these samples is the source for the Northwind.dll this way a person could presumably create a BHIS.dll or some other database accessor dll paterned after the northwind.dll and experiment with Cw in a data collection that had some meaning to the person rather than the Oft used and now tiring Northwind... ( There just is not enough data there to make anything experimental be of much use to the PHB's of the world ).

This work looks like a good start at moving things forward in the world of programming. It's still only a start though - while Java weenies are still patting themselves on the back for using a language that has garbage collection but doesn't have an excess of parenthesis - I can't be the only person who thinks that a vast amount of the flexibility of the runtime environments we have now is wasted on simplistic languages like Java and it's look-a-likes (e.g. C#).

Mainstream language designers and compiler developers seem to be stuck in the 1970's, still following the old C compilation model more-or-less. Why do we have to have this old fashioned edit-compile-run-debug cycle? Why do we even need source files when we're compiling to platform independent code? You'd only have extend the metadata facilities of MSIL a little in order to hold comments and then you could do without the old-school text file (yeh, I know "real programmers" are kindof wedded to idea of editing text files) and just have an editor that works on the MSIL in the users preferred format. Edit-and-continue wouldn't seem so much like voodoo if this was the case, it would merely be a logical extension to the way things normally worked - instead of editing an assembly on disc, we edit in memory and re-JIT.

This C-omega thing looks interesting, mixing in code with different grammars. I'd like to see this extended with a plug-in architecture to make it more generalised - this should be possible as long as the langauges are all LL(k) (i.e. parsable with recursive descent parsers). The plugin can do not only what's necessary to execute the code but also provide the "live analysis" needed by the editing environment.  While we're on this theme, why does source code have to be a string of text? Without resurecting long-gone notions of "visual programming" languges, I'm thinking about things like mathematical equations. Wouldn't it be great if you could embed math code in your C# by writing equations like you do in Mathematica and have those equations rendered in the source editor the same way they'd be written  in a math textbook?  

OK, that's enough dreaming for now....

Just to follow up on a couple of new questions:

1. What's the relationship between C# and Cw? Everyone asks about this! Ernie Booth asked me this, and I posted the following to his Cw forum site (www.omegaengine.com - take a look!):

Is Cω an early release of C#3.0? We get asked this all the time. Indeed a number of (non-MS) websites have stated this as a fact. The short answer is no! We are quite separate from the C# and Visual Studio teams. We are in Microsoft Research, and Cω is a purely research project. Our main research interest is in the design and implementation of advanced programming language features. We released the compiler so our colleagues, academic and non-academic, can play with the system and hopefully their feedback will drive our future research. Again, research not product development. That said we do have contacts on the development side, and they are aware of what we’re up to (we don’t work in a vacuum!). Here’s a quote from Scott Wiltamuth which hopefully clarifies matters:


"The C# team is excited about Cω and other C#-based research projects that Microsoft Research Cambridge is working on. We have no current plans to extend the C# language in this direction, but will continue to observe the progress of Cω and other MSR-Cambridge projects.” -- Scott Wiltamuth, C# Product Unit Manager
 
2. Cw as a commercial application language. We're in Microsoft Research, so our prototype compilers are simply prototypes. We think the Cw compiler is pretty solid, but it comes with no guarantees. If you want those, you should really use C#, VB.NET or one of our commercial compilers.

3. I have a cool idea for a new language... That's great! Languages are a fascinating place to be doing research. Take a look at ACM Sigplan, ACM ToPLAS, POPL, PLDI, ECOOP, OOPSLA ... and see what people are up to. It's an exciting place. If you have ideas - these are the places to publish them.

Gavin

Keep up the vital work!

Just one quibble: the assumption here is that c-omega T-SQL-like syntax will make every effort to respect the ANSI-92 SQL syntax so that we are not forced to use "INNER/OUTER JOIN" stuff and can use "=*" or "*=". Also, I would liked to see how stored procedures are treated in c-omega.