OS Jam at Google London: C# 4 and the DLR

Last night I presented for the first time at the Google Open Source Jam at our offices in London. The room was packed, but only a very few attendees were C# developers. I know that C# isn’t the most popular language on the Open Source scene, but I was still surprised there weren’t more people using C# for their jobs and hacking on Ruby/Python/etc at night.

All the talks at OSJam are just 5 minutes long, with 2 minutes for questions. I’m really not used to this format, and felt extremely rushed… however, it was still a lot of fun. I used a somewhat different approach to my slides than the normal “bullet points in PowerPoint” – and as it was only short, I thought I might as well effectively repeat the presentation here in digital form. (Apologies if the images are an inconvenient size for you. I tried a few different ones, and this seemed about right. Comments welcome, as I may do a similar thing in the future.)

First slide

Introductory slide. Colleagues forced me to include the askjonskeet.com link.

Second slide

.NET isn’t Open Source. You can debug through a lot of the source code for the framework if you agree to a “reference licence”, but it’s not quite the same thing.

Third slide

.NET isn’t Open Source, but the DLR is. And IronRuby. And IronPython. Yay!

And of course Mono is Open Source: the DLR and Mono play nicely together, and the Mono team is hoping to implement the new C# 4.0 features for the 2.8 release in roughly the same timeframe as Microsoft.

Fourth slide

This is what .NET 4.0 will look like. The DLR will be included in it, despite being open source. IronRuby and IronPython aren’t included, but depend heavily on the DLR. (Currently available versions allow you to use a “standalone” DLR or the one in .NET 4.0b1.)

C# doesn’t really depend on the DLR except for its handling of dynamic. C# is a statically typed language, but C# 4.0 has a new static type called dynamic which you can do just about anything with. (This got a laugh, despite being a simple and mostly accurate summary of the dynamic typing support in C# 4.0.)

Fifth slide

The fundamental point of the DLR is to handle call sites – decide what to do dynamically with little bits of code. Oh, and do it quickly. That’s what the caches are for. They’re really clever – particularly the L0 cache which compiles rules (about the context in which a particular decision is valid) into IL via dynamic methods. Awesome stuff.

I’m sure the DLR does many other snazzy things, but this feels like it’s the core part of it.

Sixth slide

At execution time, the relevant binder is used to work out what a call site should actually do. Unless, that is, the call has a target which implements the shadowy IDynamicMetaObjectProvider interface (winner of “biggest mouthful of a type name” prize, 2009) – in which case, the object is asked to handle the call. Who knows what it will do?

Seventh slide

Beautifully syntax-highlighted C# 4.0 source code showing the dynamic type in action. The method calls on lines 2 and 3 are both dynamic, even though in the latter case it’s just using a static method. Which overload will it pick? It all depends on the type of the actual value at execution time.

If I’d had more time, I’d have demonstrated how the C# compiler preserves the static type information it knows at compile time for the execution time binder to use. This is very cool, but would take far too long to demonstrate in this talk – especially to a bunch of non-C# developers.

Eighth slide There were a couple of questions, but I can’t remember them offhand. Someone asked me afterwards about how all this worked on non-.NET implementations (i.e. Mono, basically). I gather the DLR itself works, but I don’t know whether C# code compiled in the MS compiler will work at the moment – it embeds references to binder types in Microsoft.CSharp.dll, and I don’t know what the story is about that being supported on Mono.

This is definitely the format I want to use for future presentations. It’s fun to write, fun to present, and I’m sure the “non-professionalism” of it makes it a lot more interesting to watch. Although it’s slower to create text-like slides (such as the first and the last one) this way, the fact that I don’t need to find clip-art or draw boxes with painful user interfaces is a definite win – especially as I’m going to try to be much more image-biased from now on. (I don’t want people reading slides while I’m talking – they should be listening, otherwise it’s just pointless.)

18 thoughts on “OS Jam at Google London: C# 4 and the DLR”

  1. Seems to me that the big value here is that the format forces you to simplify and focus on the big-picture, important aspects. As you say, text slides are much easier to create when done in a presentation program, but that’s not necessarily a good thing.

    By the way, as far as the images in your blog go, I have two main concerns:

    — The entire blog post contents are copied to your RSS feed, including the images. It’s bad enough to have a large blog post show up in the RSS feed, but when the images are there too it does get a bit out of hand

    — Your particular format has text adjacent to the images, rather than below. I understand the attraction to doing it that way, but unfortunately it’s not very browser-friendly. My default window layout left just enough room on the right for about half the pixels of the first character of each line of text. And unfortunately, that particular browser (Safari on the Mac) has an awful “zoom window” UI, so I had to drag the window manually in order to be able to see the text (which I hate doing, because it changes the default window size globally for Safari).

    Instead of laying things out as a table, if you had instead made each image and the associated text contained within a , with a after the text , then for folks who already had their window large enough, they would see the two side-by-side, and for the rest of us, the text would flow below the image.

    Alternatively, just don’t be so “fancy” with the layout. :)

    Like

  2. Pete: I tried a few things before settling on the table, including a div per slide. I didn’t try inline-block though… will give it a try.

    I don’t know of any way of changing how much gets included in the RSS feed, unfortunately. Will check the settings.

    One problem is that there’s quite a lot of empty space on the slides. I could trim them, but that might look odd in a different way. Will give it a try over the weekend, but it won’t be tonight I’m afraid.

    Like

  3. fwiw, I thought the layout worked pretty well in Google Reader. I find it’s a pain when I’m forced to click-through from my feed reader to read the full content, though maybe it’s not such a problem if it’s a one-off.

    Like

  4. “I don’t know of any way of changing how much gets included in the RSS feed, unfortunately. Will check the settings.”

    I don’t think there’s any way to automate it. But, Community Server allows you to provide specific RSS content for each article. You can excerpt the article (not a bad idea for any lengthy article), or just do copy/paste minus the graphics.

    “One problem is that there’s quite a lot of empty space on the slides. I could trim them, but that might look odd in a different way. Will give it a try over the weekend, but it won’t be tonight I’m afraid.”

    No rush. I’ve already read the whole article. :)

    As far as the empty space goes, I actually like having the whole context. White space is only wasted when it’s not pulling its own weight; but in this case, as the “negative space” on your slides, it’s as informative as the “positive space”. It focuses the attention, by providing a clean background for the content to live in, and provides a uniform surface on which your points are presented.

    If I had to choose between hacked slides but an article that fit my browser without any work on my part, and intact slides but an article that I have to reconfigure my browser window to read, I think the latter is preferable.

    Fortunately, I don’t think it’s an either/or proposition. Just a matter of formatting. (Oh, and just to be clear, in case it wasn’t from what I wrote before: I’m suggesting that each image be contained in a “inline-block” div, and that each text going with each image be contained in its own “inline-block” div. In other words, pairs of adjacent ‘s with a between each pair).

    Like

  5. Excellent format, minimal context and structure from the slide, most information coming from explanation.

    Your writing sucks almost as badly as mine ;)

    Time till someone makes an iPhone app that lets you make this sort of quick slideshow on the fly?….

    Like

  6. According to the Mono road map

    http://www.mono-project.com/Mono_Project_Roadmap

    Support for the dynamic keyword in the mono compiler will be available in the 2.8 release. The 2.8 schedule is currently TBD. Currently, the 2.6 release is scheduled for Sept 2009, so probably 2.8 will be released in 2010.

    In general if a language feature doesn’t require a CLR change post 2.0, and the assemblies referenced are available then assemblies compiled by one of MS’s compilers will run on Mono without any required changes.

    Like

  7. @Anthony: The problem is that the Microsoft.CSharp assembly *won’t* be present unless either the Mono team implement it or MS decides to Open Source it. I can’t think of any other cases where this has happened in C#. Will check the situation with Miguel.

    Like

  8. I wish you had mentioned in the smiley face slide that Mono is an open source implementation of .NET and that most of what you covered runs on Mono/Linux.

    Users that are tracking Mono from SVN already can use some of the C# 4.0 features and hopefully by Mono 2.8 we will have `dynamic’ implemented and shipping (roughly at the same time as MSFT ships)

    Like

  9. Regarding Microsoft.CSharp assembly: if this is the final name for it, we will ship this assembly with a compatible API but an open source implementation.

    I once heard that pieces of C#’s 4.0 dynamic support are actually in the open source code for the DLR, but I have to check what the exact situation is today.

    Worst case scenario, a team of passionate hackers will implement a fully open source implementation.

    Since we are open source, you do not have to wait for us to do the work. You can jump right into the project and help us make it available sooner than Mono 2.8.

    Like

  10. @Miguel: I may have done at the time – not sure. (This isn’t a transcript, just what I think I may have said!) I’ll certainly edit this blog post to make it clear here.

    Like

  11. John,

    You wrote..

    “The problem is that the Microsoft.CSharp assembly *won’t* be present unless either the Mono team implement it or MS decides to Open Source it”

    Yes this is obvious and why I wrote “and the assemblies referenced are available” assuming that they were coming from someone and most of the time the Mono folks on mono..

    Like

  12. Please keep the Feed Full-Text!

    Nothing is more annoying than going through my feeds and having to click each link to read it!

    I can’t believe people would ask for less information. If you want a truncated feed you could simply use some sort of feed proxy that does that. But I believe the general public likes fulltext!

    greetings Daniel

    Like

  13. I really liked the way you made your slides “unprofessional”, it makes it fun to watch and read. I also like the askjonskeet.com link on the first slide.

    Like

  14. Keep the full RSS feed please! Having a full content RSS-feed makes it possible for people to read your content using the tool of their choice. It’s great for people who are visually impaired. If you are to publish limited RSS-feeds, please do it in another feed.

    Like

Leave a comment