Wow - what a day. It started with discovering that the turnout was well past my expectations. Mike Lehman (the technical evangelist for compilers at Microsoft, and the event coordinator) told me that we hit the limit and had to turn people away. I'm glad I arrived early go get some good parking and a good seat.
The material I'm posting now is probably of limited interest to a LabVIEW developer, but I find it very interesting computer science information. Feel free to browse and comment.
The session started with an overview by Anders Hejlsberg (inventer of C#) on the LINQ project. The basic idea here is to integrate the sorts of structured queries handled by SQL directly into the C# language, and also extend the functionality into other data structures, such as XML or objects. Lots of good information in the links above, so I'll say no more on it here.
Ruby is a dynamic scripting language that has recently reached a new level of exposure due to the "Ruby on Rails" framework, targeted at building web applications. John Gough gave the presentation on the efforts involved in porting Ruby to the .NET CLR. I have to say I was left with the impression that not all languages are well suited for being targeted to the CLR...Ruby has some very unusual language concepts that make it difficult to map, which results in a large interop layer being required to run on the CLR. On the flip side, they have managed to implement a fair amount of the Ruby language in a fully compiled platform - no small undertaking.
The good news is that Microsoft is definately focusing more and more on dynamic language support (see later), and this effort should definately give them food for thought :)
Another very exciting outcome of the project was their implementation of bison/yacc for .NET!
Christopher Diggins from Microsoft presented a language he's been developing on the side which I found a facinating, if very fast, presentation. Inspired by the Joy programming langauge, CAT provides a functional structure with transformations to enable source code optimizations. It retains very strong roots to the functional space, which explains the very mathematical feel I got during the presentation. The concepts of transformation are an interesting one, since in mathematics, may problems that cannot be solved in one form are solvable if you perform the correct transformation on the equations. The same may be true here, especially for proofs of correctness or other such analysis.
I also must say I liked the concept in CAT of explicitly declaring the imperative language blocks so as to allow the compiler to optimize around them correctly.
Either way, this is one that is going to take more research - I wished we could have spent more time on it. Hopefully I'll be able to corner Christopher.
Created by the need of a couple of web site developers, PageXML is a good example of a domain specific language (a language designed for a specific market - in this case, building web apps). They have not yet released their first version (as you may have guessed if you hit the above site soon after I post this), but they did show an example of a site built with it.
The design is to have an XML document with elements defined for specific actions. Some are the basic control, such as if, loop, while, etc. Others are specific to web pages, such as the one for URLs.
Unlike the Ruby presentation, this one was able to show a language that was able to map very well to the CLR system and actually have performance improvements over the original C-based implementations (.NET JIT compiler over the C-engine interpreter)! If it sounds familiar, it's because I've posted about this one before - specifically on how you can pull in IronPython scripts into LabVIEW.
What was new this time was the demos. The first one was near and dear to my heart - the integration of Powershell libraries and IronPython. I'd never really thought about it in those terms, but he's right - Powershell is a dynamic language.
The second demo was even more impressive - and I'm not even a VB guy. First, VB.NET is a dynamic language, although in the original effort to go point-to-point with C#, it's easy to forget the fact (most VB.NET example code you see is filled with static type declarations that aren't actually required - although I'm not saying they're a bad thing...just not actually requried).
So, what was the demo? A port of the IronPython interactive shell to a VB.NET interactive shell! There he was, typing away snips of VB.NET code at a prompt. As I said, it's easy to forget what you can do with VB.NET, but you can :)
This session by Markus Lumpe was one in which I'm still trying to fully understand the "why?". The Classbox concept has been around for sometime, apparently, and was originally applied to Smalltalk. There has also been work done to bring the concept to Java, but this project was the recent effort involving .NET - and apparently the first to attempt to provide static implementations during compile, rather than dynamic interception.
I can understand the value of extensions - the aspect programming concept for layering functionality across classes has always been an interesting idea to me. However, I obviously don't fully understand the use-case model...more research for me :)
Versioning in the 21st Century
Okay - going out on a limb on this one, but the talk by Susan Eisenbach on extensible versioning seemed like handing a loaded gun to a teenager with a drinking habit. The justification seemed to be that because developers often failed to correctly architect their code, we should develop a loader system that allowed for the user to be able to redirect code bindings to any other class that had the same signatures.
Now don't get me wrong - versioning is a difficult problem to get right at the best of times and the .NET Fusion infrastructure isn't the easiest thing to deal with. But this just seems like the wrong approach. The .NET engine already provides a solution to handle versioning correctly, and a set of features for resolving types in cases where you need a bit more flexibility (see the ability in the SLQ/Server hosting to pull assemblies out of a database).
Ah well, can't please them all. This time, I'm the them.
I'm sorry to say that I missed this presentation complete due to another meeting I needed to attend. You'll need to search around for someone else's comments. However, William Cook, the presenter, designed the original AppleScript - gotta love this symposium. He's now at UT Austin, so we did have a chance to do a little "hey, you're from Austin too?"
This is one I loved to see - a language where the designer spells out very clearly their expectations! Spec# is a research project going on at Microsoft Research, but is at the state where you can download it to play around with it yourself.
Anyway, the idea is that in your code you specify rules about the expected behavior, and the compiler validates both the implementation, as well as the client code, on those rules. For example, I could declare that a string argument should never be null. Similar to the const concept in C++, it then makes that a requirement on any caller. You can also declare what are known as invariants, such as "This member variable can never be less than zero". The end result is that the compiler quickly corrects you when your expectations and your code don't match.
As the presenter, Mike Barnett, said - it allows you to capture the designer's intentions right in the code. I really hope to see more of this in the future.