Even though I haven’t finished my ETech postings, I’m already onto another event. This week, thanks to an invite from Michael Lehman, I’m sitting in on a Compiler Lab discussing implementing other languages for CLR. The first day was about LINQ. Much of the info is rehashed from PDC or the docs up on MSDN. However, I have learned a few new things.

• One of the standard features of LINQ is Extension Methods. That enables you to declare a static method like “static void Foo(this string source)” and then use it like “stringvar.Foo()”. Apparently, they are considering adding other types of extension members including properties and fields. The idea of extension fields is somewhat scary but powerful.
• LINQ uses something Anders called deferred query execution. The query isn’t executed until the values are asked for (typically by calling foreach on the query). That means you can compose queries to your hearts content with no perf impact until you actually invoke the query.
• Query Comprehensions in C# and VB is a pattern implementation in a similar vein to foreach. Foreach is relatively simple shorthand for iterating through an collection by calling IEnumerator.MoveNext until it returns false. While LINQ enables arbitrary composition of queries, there is obvious gravitational pull towards the SELECT / FROM / WHERE / ORDER BY / GROUP BY approach favored by SQL. So if you build your own query operator, you can include it in a LINQ query, but C# and VB won’t be able to include it in the Query Comprehension syntax. Probably not a big deal, given the breadth of standard query operators as well as the deferred query execution, but it’s good to understand how the abstraction works.
• I want to know more about how DLinq is implemented. I’ve been refining my thinking about data since working with Ning’s content store and I’m convinced of the need for a simplified datastore. SQL is designed for significantly complex database schemas, which means a significantly complex development environment.
• I’m looking much more closely at VB, given the new features in VB 9.0. Not only the LINQ stuff from C# like type inference, extension methods and anonymous types but also VB specific stuff like XML Literals and Duck Typing. Combined with VB’s existing support for late binding, there are compelling features to make VB attractive over C#.
• I’ve been hanging out with Brian Beckman. He’s a hoot.
• I think I need to take a deeper look at F#.

Terra Nova is not the usual place I go to get news around programming language improvements. But they linked to a great presentation from POPL 2006 by Tim Sweeney of Epic Games. Tim’s talk is called The Next Mainstream Programming Language: A Game Developer’s Perspective and it talks at great length the major issues facing game developers today. As Nate Combs at Terra Nova remarked, most of these issues are not specific to the game industry, but will likely be seen there first.

Most interesting (to me) was the issue of concurrency. Tim uses Gears of War for all his examples. Of course, Gears of War is an Xbox 360 exclusive. Xbox 360, as many of you probably know, has three hyper-threaded CPUs for a total capactiy of six hardware threads. Herb Sutter talked about this in his DDJ article The Free Lunch Is Over. Tim points out – rightly so – that “C++ is ill-equipped for concurrency”. C#, Java and VB aren’t much better. Tim conculdes that we’ll need a combination of effects-free non-imperative code (which can safely be executed in parallel) and software transactional memory (to manage parallel modifications to system state).

Tim also touches on topics of performance, modularity and reliability. And he has an eye on the practical at all times. For example, he points out that even a four times performance overhead of software transactional memory is acceptable, if it allows the code to scale to many threads.

Anyway, it’s a great read so check it out. Also, MS Research has a software transactional memory project you can download if you’re so inclined.

Certainly not my father’s C++. I sat thru a presenation on VC++ 2005 today. Wow, I hadn’t realized all the coolness there.

First off, all the syntax is working it’s way thru the standards bodies, so no more underscore underscore syntax. It makes the code somewhat easier to read, but more importantly it’s following a similar standardization process to CLI and C#.

Secondly, you can now use all the native C++ features (templates, multiple inheritance, buffer overrun protection, etc) and all the CLI features (garbage collection, generics, language interop) together. Previously, you had very limited choices for mixing the two coding idioms. No longer – go ahead and mix and match. This gives you the best of both worlds. Use templates, and expose them to other .NET languages as generics.

Finally, it brings deterministic finalization to .NET. In VC++ 2005, you can declare both a destructor (used when a class goes out of scope or is explicitly deleted) and a finalizer (used when the class is garbage collected). This is similar to the whole IDisposable approach for classes that wrap unmanaged resources (file handles, network sockets, etc). Actually, it’s identical to IDisposable because that’s how it’s implemented! And it works both ways – if you instance a managed class that implements IDisposable “on the heap” then it will automatically call dispose at the end of scope. For example:

{  //C++ Version
   FileStream fs = FileStream(path, FileMode::Create);
   fs.Read(...);
   fs.Write(...);
}  //fs.Dispose called automatically

Even though the FileStream is implemented in C#, it behaves here like a stack type and is destructed as you would expect. In C#, you’d have to use a using statement to achieve the same effect. For this trival example, it’s not that big a deal. But if you have multiple stack instances created at different times within a scope, this helps out immensely.

Not sure I would move to C++ for all my managed programming, but I’ll certainly be giving VC++ 2005 another look.

I just read Dare’s awesome article on C-Omega. If I had any time at all, I’d experiment with it to rewrite dasBlog (well, at least the back end parts of dasBlog anyway). Of course, I don’t have any time at all, so it’s not going to happen (well, at least I won’t make it happen)

Several people have pointed out Herb Sutter’s great article on concurrency entitled The Free Lunch Is Over. When I blogged last week about new possible features of “full-grown” OO languages I mentioned dynamic typing but I didn’t think about concurrency. I think Herb is right: “programming languages…will increasingly be forced to deal well with concurrency” as applications get more CPU bound. Maybe I need to take another look at Comega (or Cw). Cw extends C# in two areas – data typing/querying and concurrency. The concurrency extension used to be called Polyphonic C#, but the name got changed when it merged with Xen/X#. (BTW, there’s a new Cw release (v1.0.2) but no specifics as to changes other than no longer needed VS.NET 2003 to be installed in order to use it.)

Cw adds the idea of asynchronous methods and something called chords – sets of methods with the same method body. The chord method body in only executed when all the associated methods have been called. In the simple buffer tutorial, the buffer class has a synchronous Get method and asynchronous Put method. If you call Get before Put, it blocks until Put is called, then the method body is executed. If you call Put before Get, then the Put call returns immediately (it is async after all) but the call is queued so that when Get is called, the method body is executed immediately. FYI, the Cw docs have a variety of other tutorials of async methods and chords.

BTW, speaking of my post on full grown OO languages…My father suggested that I not jump to conclusions regarding the X-develop‘s support for what they term “toy languages or little domain specific languages”. In fact, Hans Kratz of Omnicore (which makes X-develop) had this to say:

This comment on our website was not intended to bash DSLs at all. Instead we wanted to make clear that the plugin API in X-develop is powerful enough to allow integrating support for “full-grown” languages without placing arbitrary restrictions on language complexity.

For a language developer/integrator this is a plus regardless if he wants to integrate support for a DSL or “full-grown” programming language.

Makes sense. Maybe I was just too sensitive to the use of the word “toy” so close in proximity to “DSL”. Sorry about that Hans.