Hey C# Team..

What is after LINQ?

Are we going to see this

transact (SomeDataSource)

{

    //burn the db.

}

commit

{

    //We did it , its done.

}

rollback

{

    //oops. sorry we messed up something.

}

When is this going to be a reality?

Also, when is XML literals be available in C#, like it is going to be in VB?

Yeah, so whats after LINQ?

Uhm, why would they build database oriented syntax right into the language?

LINQ isn't about databases, its about creating expressions that can be evaluated.. just so happens what is the hardest part with an ORM right now (making a easy and reliable query system on these objects) can be fixed by using LINQ..

Objects should be handling stuff like database transactions and rollbacks.. not the language..

stevo_ wrote:

Uhm, why would they build database oriented syntax right into the language?

LINQ isn't about databases, its about creating expressions that can be evaluated.. just so happens what is the hardest part with an ORM right now (making a easy and reliable query system on these objects) can be fixed by using LINQ in a perfected form..

Objects should be handling stuff like database transactions and rollbacks.. not the language..

I am talking about having these transact, commit, rollback keywords as first class citizens in the language, that allows me to do translations of SQL type with any data source object, be it a the registry, an access database, any thing that supports transactions.

This is going to be important with the new file system that is based on Transactions. Transactional-FS, and multi-core processors etc..

Such support needs to be deep in the language. And I want to be able to do it too.

There are areas in where this is useful specially with concurrency.

Sorry, but I don't see why this is any different to try.. catch.. finally.

This is built into the language at a low level, and is generic enough to be used in many ways.

How does your system actually make anything different?

IMHO, "threadable { }" block would be more useful. This block can mean "run enclosed code on different thread (or even core?) if possible"

But commit/rollback in code... quite weird... like to catch exceptions in "catch" block.

stevo_ wrote:

Sorry, but I don't see why this is any different to try.. catch.. finally.

This is built into the language at a low level, and is generic enough to be used in many ways.

How does your system actually make anything different?

While its superficially looks like a try catch block, in the the way it works its very different. We are talking about a transaction here that will commit or fail. About Atomic processes. Its a natural progression from query integration into the language to be able to transact data sources.

So when you transact across something, and it fails, you cant recover from that, and the transaction is declared failed (exec rollback block). If it goes through, then execute the commit code block. the Transact itself will happen in an atomic way, just like transaction happen in SQL Server.

This allows you to write your own resources that can be used in transaction like execution plans.

maybe you don't see a use for it now, because we dont have an abundance applicability. However, there will be in the future, with Transactional Memory, Transactional File System, Transactional Processing with multi-cores.

This is just my suggestion. I am still not sure what the C# team has in store. LINQ was a big step forward, and I like to see C# become better and better as a general purpose programming language.

BlackTiger wrote:

IMHO, "threadable { }" block would be more useful. This block can mean "run enclosed code on different thread (or even core?) if possible"

But commit/rollback in code... quite weird... like to catch exceptions in "catch" block.

But that is already present in someway or another with the Threading classes and the way you initialize them (ThreadStart...).

Think about atomic operations, and their applications. We need this in C#. If the past is any prediction indicator of the way C# team thinks, maybe they are  already thinking about such things.

Or I may just be wrong:P

BlackTiger wrote:

IMHO, "threadable { }" block would be more useful. This block can mean "run enclosed code on different thread (or even core?) if possible"

You can already do this with just a little bit of your own "behind the scenes" code.

Something like:




void FancyButtonClicked()
{
   // This is called on the UI thread

   // Some local variables
   int someVar = 0;
   
   m_myFancyButton.Enabled = false;

   // Do something on a background thread, without blocking the UI
   DoBackroundTask(delegate()
   {
      // Do some process intensive task here on the background task...
      // it is ok to use someVar in this background thread...
      someVar++;
   });

   // Background thread is now done
   m_resultLabel.Text = someVar.ToString();
   m_myFancyButton.Enabled = true;
}

Then, you have to create the DoBackgroundTask method to take a delegate as a parameter.  It takes this delegate and uses the tread pooling functionality to schedule it on a pooled thread.  It also has the logic to know when that delegate ended, and spins around in a loop doing Application.DoEvents (this ensures you UI stays responsive) until the delegate running on the pool thread finishes.  Yes, you need to do a little bit of upfront work to make the functionality work, but once you have DoBackroundTask working it is extremely easy to use the functionality anywhere in your code, such as the example I gave above.  The language automatically creates a reference to the someVar variable and it is visible inside the block of code executing on the background thread, and any changes will be reflected back to the code outside the block of background code. 

I actually have a version of DoBackgoundTask that blocks the calling thread and one that does not block the calling thread.  Very useful.

Check out TransactionScope.  It does this exact function (minus some trivial flow control) without modifying the language, which most of us view as a bad thing anyway.

I hope they maintain the boundary between software developers and database programmers.

littleguru wrote:



John Melville, MD wrote: Check out TransactionScope.  It does this exact function (minus some trivial flow control) without modifying the language, which most of us view as a bad thing anyway.

Yes, Secret should have a look at that. It's already in .NET and shouldn't be integrated into .NET. What would be cool - and will come - is more stuff to target multi core cpus!

Thanks John, and littleguru, I am certainly going to take a look at that.

As for more stuff that tharget multi-core cpus, MS talked about that in a general term, but they are silent on how they go about doing it.

I guess we have to wait and see .

SecretSoftware wrote:



littleguru wrote:  John Melville, MD wrote: Check out TransactionScope.  It does this exact function (minus some trivial flow control) without modifying the language, which most of us view as a bad thing anyway. Yes, Secret should have a look at that. It's already in .NET and shouldn't be integrated into .NET. What would be cool - and will come - is more stuff to target multi core cpus!

Thanks John, and littleguru, I am certainly going to take a look at that.

As for more stuff that tharget multi-core cpus, MS talked about that in a general term, but they are silent on how they go about doing it.

I guess we have to wait and see .

They have talked about it through Plinq. which includes support for transactions at the language level also (I think, will have to look into that more, I know polyphonic C# had some transactional support).

Check out Eric Maijer's paper's on thoughts of Linq 2.0 and problems that need to be solved there.

from xtech 2007,  http://2007.xtech.org/public/schedule/paper/60
or his web site which has some white papers. 

The primary language features discussed are "Just as we provided deep support for XML in Visual Basic, in LINQ 2.0 we hope to directly support relationships and updatable views at the programming-language level."

More later as I have time. but concurrency and solveing the last mile issue of the impedance Mismatch (which will apparently add language features) on on the table and has been discussed several times.

Douglas

From DouglasH's link of Eric Meijer's Xtech 2007 paper:

Eric Meijer wrote:

On both the client and the server, we do not assume the existence of a native .NET runtime. Instead we will target any available existing runtime. In particular we anticipate that the client is a browser that supports JavaScript, and we have implemented a complete deep embedding of MSIL into JavaScript.

Umm, wow!  Is this Nikhil Kothari's Script# he's talking about, or is Eric talking about something deeper than that?

JavaScript, this generation's assembly language... Steve Yegge of Google ported Rails to JavaScript via Rhino.

JChung2006 wrote:



From DouglasH's link of Eric Meijer's Xtech 2007 paper:

Eric Meijer wrote: On both the client and the server, we do not assume the existence of a native .NET runtime. Instead we will target any available existing runtime. In particular we anticipate that the client is a browser that supports JavaScript, and we have implemented a complete deep embedding of MSIL into JavaScript.

Umm, wow!  Is this Nikhil Kothari's Script# he's talking about, or is Eric talking about something deeper than that?

JavaScript, this generation's assembly language... Steve Yegge of Google ported Rails to JavaScript via Rhino.

Yes. Wow!

JChung2006 wrote:



From DouglasH's link of Eric Meijer's Xtech 2007 paper:

Eric Meijer wrote: On both the client and the server, we do not assume the existence of a native .NET runtime. Instead we will target any available existing runtime. In particular we anticipate that the client is a browser that supports JavaScript, and we have implemented a complete deep embedding of MSIL into JavaScript.

Umm, wow!  Is this Nikhil Kothari's Script# he's talking about, or is Eric talking about something deeper than that?

JavaScript, this generation's assembly language... Steve Yegge of Google ported Rails to JavaScript via Rhino.

Work comes from the tesla group.  here is a link that describes some of it from earlier work. 

http://oakleafblog.blogspot.com/2007/02/erik-meijer-to-keynote-qcon-london.html

It is from that group where Linq to xsd is coming from also. 

Douglas

These would-be generalized object-level transactions look somewhat dangerous in an imperative side-effecting I/O world. Not that they can't be useful in contained scenarios.

It may still be a good idea to embed XML into the language, but what about the evolution of two languages. Is this going to cause problems?

I really feel that it isn't necessary or that good of an idea to tie C# to XML directly.

The first reason is to keep the programming language independent of any specific syntax like XML. And also to keep it independent of XML as a data model.

It's better to have language features that make it easy to express the XML data model (infoset) easily. I believe some of the new C# 3 features may facilitate that.

On the other hand...

I have long felt it would be quite interesting with a programming language expressed in a metalanguage like XML and requiring tool support for proper display. It would mean that it would be much more extensible and flexible. Right? If the language was expressed in XML to begin with, well then it would be even easier to support XML fragments out of the box. It could also be built on a more general model like RDF et al. That will mean more overhead but also more freedom in shaping the language I think...

I also find program and data visualization interesting. As well as visualizing domain specific programs and program fragments. Having an extensible language with built-in support for inline domain specific languages could be interesting. It does require rethinking programming since it will become interactive as dealing with a graphical user interface and will rise above typing in characters in many situations, although also complementary. It could also mean presenting different graphical views of the semantics. In effect semantically skinnable code.

At least the idea appeals to me.