07.31.2006 07:29:24 PM (Last Update: 03.26.2009 08:09:05 AM)
This conference has a lot more attendees than Compiler Lab 2006 did. I estimate that there's approximately 80 people in the room, which was encouraging to see.
The keynote was given by Anders Hejlsberg on LINQ (Language Integrated Query). I saw this presentation at Compiler Lab 2006, so most of this was review for me. He stated that queries, set operations, and transforms should be 1st-class citizens, like classes and objects ("queries should just 'be there', like for loops"). Rather than going through a bunch of slides, he drove his talk through code examples. He showed how you can use LINQ to query all the processes running on his machine, filtering the query based on the working set size. By doing this he demonstrated anonymous types and type inference. It was interesting to hear him talk as he did his string formatting - I found that by doing that it made it easier to make the {1,12:N0} format string off-the-cuff. He then showed how he could join that object query with a LINQ-to-SQL query. An interesting thing to do is to set the Log property of the DataContext to show what's going on during a query (db.Log = Console.Out). Then he took the results of that query and projected it as a RSS 2.0 feed to show LINQ-to-XML (remember the Edit -> Paste XML as XElement menu option!). After the 1st demo, he talked about the C# 3.0 specifics (like type inference) that work very well with LINQ. He showed that expressions are turned into method calls (which usually are extension methods). He goes into detail how a LINQ query is processed by the compiler. I have to admit, I didn't get what a lambda expression is - Func<Customer, bool> filter = c => c.City == "London" - it looked like a shorthand way to do a on-the-fly delegate. However, the more Anders talks about LINQ, the more I understand lambdas and what Func<> is (it's kind of weird to see C# starting to become very functional-like). It's really cool to see how generics, enumeration, and other pre-LINQ features are used extensively in LINQ. Anders did mention that they're planning on having a refactoring where you can lift an anonymous type as a nominal type that can be shareable. There were a lot of (good!) questions on LINQ and I do have a fear that when .NET 3.0/VS 2007 hits the streets there will be a lot of confusion about what's really going on with LINQ. However, LINQ in the long run will eventually permeate everyone's .NET programming experience. Unfortunately (for those who haven't spent any time with LINQ) Anders ran out of time so he couldn't cover as much as he wanted to - he really should have been given 90 minutes to talk, rather than 60.
Sidebar: I wonder if expression trees and dynamic compilation could be an "easy" way to make dynamic proxies?
The next presentation was done by John Gough, who talked about his work implementing Ruby on the CLR. First, he covered the essentials of Ruby. This really wasn't an introduction to Ruby per-se; it was focused on the history of Ruby. He then moved to his Ruby.NET project, which he said is a compiler, "not an interop wrapper, or a...standard interpreter". Specifically, he talked about the problems and issues he's run into - the main one being "there is no authorative definition of the language semantics". In Ruby, everything is an object with a well-defined class. However, Gough warns that Ruby classes shouldn't be mapped to System.Type as class definitions can be changed at runtime. Gough talks about their own built-in Ruby classes (e.g. Ruby.Object, Ruby.Class, etc.). The method binding issues seem pretty complex at first due as methods can be attached to one object of a given class but not another, so even though both objects have the same class, they don't have the same features. The tree that is generated to represent a class with a mixin is quite daunting - I don't envy the work it takes to get Ruby to work on the CLR! He mentioned that he did not use delegates to implement the methods; rather, he defined a class called MethodBody to represent every method, which he said allows for method specialization. A lot of the implementation details hint at what Jim Hugunin talked about at Compiler Lab 2006 relative to IronPython. For example, Gough mentions a "activation frame" to support closures - IronPython has a FunctionEnvironment. At the beginning of the talk, Gough mentioned that the CLR needs a standard API to support a lot of the featuers that dynamic languages share, and this seems like one of those. I wished Gough would've had more Ruby code examples - it was hard to follow his talk at times when he talked about implementation details (a good example of this is when he talked about blocks and what happens during a return - I really couldn't figure out what he was getting at). Gough ended with the current status of Ruby.NET. It currently does not have support for continuations and threads, although he states it passes "all 800-odd tests of the basic test suite". He said there's currently lots of room for performance gains, but right now his group hasn't spent a lot of time on performance tweaking. He also mentioned some spin-off projects/tools from Ruby.NET, like a PE-file reader/writer (PERWAPI), a C# parser generator (GPPG), and a scanner generator which emits C# (GPLEX).
After a brief break, Christopher Diggins did a presentation on Cat, which is a "stack-based functional language". Cat is intented for human-use, even though is it a low-level language. Diggins calls it a "multi-paradim compositional language" as it's based on the composition of functions. Diggins moved really fast through his slides, so it was hard to keep up with his material, but he only had 30 minutes to cover Cat. I would've like to see more practial examples of Cat rather than a theoretical discussion of the language. It seems like Cat is a Lisp-like assembly language. Someone in the audience asked the question that I think everyone was thinking: "Where would you use Cat?" His answer...well, I couldn't really follow it. Diggins has a lot of energy when he talks and he's definitely passionate about his work, but I think he needs to work on communicating his ideas better.
Mark and Paul Cooper did the last talk before lunch on PageXML, which they called "a DSL for developing web applications". Basically, PageXML seems like a way to write code in XML, and it's processed by a .NET HttpModule. I really didn't see a big benefit to using PageXML - I personally would use a plug-in architecture to allow developers to use their language of choice to inject their code at specific parts of the page processing (which is what ASP.NET offers anyway). I wouldn't want to write my code using XML.
After lunch, Jim Hugunin talked about IronPython and dynamic languages in general. Similar to Anders' talk, this was a repeat of Jim's talk from Compiler Lab 2006, but he did throw in some new stuff at the end. He talked about how initial implementations of Python on .NET were terrible and gave dynamic languages on .NET a bad reputations. However, Jim found out that a proper implementation made IronPython faster than the standard implementation of Python. He also mentioned that .NET 2.0 made his implementation faster than .NET 1.1 without any work on his part via dynamic methods, delegate performance improvements, generics, and general platform improvements. He goes through how Python code is mapped to the underlying IL. He continually drives home the point that by targeting the CLR you automatically get all the benefits of a lot of man-years of work. However, you still need to address dynamic language issues correctly (i.e. don't use Reflection!). Jim wanted a true Python implementation yet have seamless integration with the Framework and Visual Studio. He went through a quick demo of IronPython in Visual Studio, which was very nice to see. Jim said that they're almost 100% on the Python standard tests, but they're not perfect yet. He showed how .NET-minded developers and Python-minded developers sometimes clash (e.g. the Trim() method on string), and how they "got around it". He mentioned other dynamic languages that are targeting .NET. He showed how PowerShell works in both C# and IronPython, which I found fastinating. He got into VB and he tried to make an argument that VB could really be a great dynamic language. Personally, I didn't buy it. His argument wasn't technically wrong; I just tend to like to use VB (and C#) as a statically-typed language (but that's my bias and I'm (slowly) getting accustomed to dynamic languages). He showed how he made a VB scripting handler, which was pretty cool. His talk concluded by talking about how the IronPython services (hosting API, dynamic type system, etc.) need to be generalized into something that all dynamic languages can use in .NET. Jim's a great presenter, and his talk was very easy to follow.
Following a brief break, Markus Lumpe talked about the classbox concept and how to integrate it in .NET. He said that the Visitor pattern allows one to extend a class via an extension, but in general this is hard to do with a published class hierarchy. A classbox basically brings the class hierarchy into another namespace (or "classbox") and adds the new method to the base class. By using the classbox idea, extensions can be added to base classes in the classbox safely, which is good relative to versioning issues. His talk was specific to C# and how he implemented a classbox in the C# world. He said they hijacked the using keyword, which I wasn't really comfortable with, although Lumpe admitted that this may not be the ideal solution. He mentioned that all of his worked was done via a modified version of the Mono compiler. He said that he wanted to target a compile-time classbox implementation, not a run-time classbox feature. This breaks some of the verifiability as it pertains to constructor base class calls, but that is easily fixed. He created a PE reader/writer - he did indirectly admit that he didn't intend on writing yet another PE reader/writer as Gough's team already had one. A lot of issues and questions came up because Lumpe's idea can be extended in the future to almost a AOP-like mechanism, and that is a thorny issue.
Susan Eisenbach followed Lumpe with a talk on versioning. She said the version number (e.g. 2.2.1) is not enough; dynamic linking is needed for versioning. What Eisenbach was really getting at (I think) is being able to load the implementation at runtime if it wasn't there at compile-time (e.g. using monolib at runtime when mscorlib was used at compile-time). More specifically, we need a better assembly resolver. Eisenbach said that this was what they called "flexible dynamic linking". Someone in the audience said that this may not be a good idea, and I agree, because if you've compiled your code against AssemblyA, you don't necessarily want to run AssemblyB's implementation. But Eisenbach said that sometimes you don't have a choice, and I do see her point. She mentioned an example where she was coding against some libraries from NASA, but they could not ship that link to other 3rd parties as NASA did not permit that. Moreover, she didn't have the choice to program to interfaces either (which would be the "right way" to do it). It was weird, though - it seemed like Eisenbach wasn't the person who was behind the code. She couldn't answer some of the technical questions and sometimes said, "I don't know - I'm guessing he did". She understood the technical aspects, but it was clear she wasn't the person who was behind the implementation details - I'm wondering if she was filling in for a colleague (the outline stated that someone named Chris Sadler was going to do the talk). It seems like their tools look interesting.
At this point, there was supposed to be a break, but someone came in to talk about VS integration. The bathroom call was way too much to ignore, though. Since I didn't catch the entire talk, I'll withhold any comments on this talk.
After a 10-minute break, William Cook talked about AppleScript. His talk started out rather differently, as he didn't go off into language ideas and issues. Rather, Cook started by talking about the simple issue of having a client talk to a server with a lot of latency and how would that be addressed. His point was to bring up the question, do the solutions impact the language? Cook said a pure OO design would hide these network issues, but it doesn't work in practice, because you can't abstract the latency problem away. He said he's primarily interested in making systems scale up and then make them simple and elegant. He went through ways that the latency problem can be solved, which led to his creation of AppleScript in 1991 (where he was limited to 60 process switches a second on the MacOS). Applications create terminology which could be used to control the application. As Cook highlighted, these expressions look a lot like LINQ expressions. However, latency is still an common issue, even with LINQ-to-SQL. Furthermore, Cook doesn't want to write LINQ syntax; he wants to write his loops and if-checks with query optimizations. He said that by abstracting the query optimizations could be made. After Cook was done, I had a hard time figuring out what Cook was trying to get at with his talk, but that could attributed to his talk being near the end of the day and I was starting to loose focus.
The last talk of the day was given by Mike Barnett on language contracts and Spec#. I learned of design-by-contract years ago when I read Meyer's Eiffel book, so I was looking forward to his talk. Barnett talked about Spec#, which is a C# derivative with contracts included. Barnett talked about how programs should be consistent, and DBC helps with this. He jumped right into a Spec# example, where using the "!" on variables said that they cannot be null. His example drove the point home how contracts ensure the correctness of a program. He also talked about how a developer can address issues when an invariant may be invalided within a method call. He pulled off a neat trick by saying, "hey, I don't need to write unit tests anymore, because my contracts state exactly what my program can and cannot do", and I totally agree with him. If your argument is of type "string!" the program will fail if a null value is passed into the method. Barnett did a good job; I wish he had been given more time to go through Spec#.
Comments
# Great Notes, from orcmid at 08.03.2006 10:02:15 PM
# Great, from Chris at 08.04.2006 06:07:17 AM
# Thanks!, from Jason Bock at 08.09.2006 01:57:35 PM