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.

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 !

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.

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

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

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.

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

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.

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?

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.

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.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.