Epicenter 2010: quick plug and concessionary tickets

Just a quick update to mention that I’m speaking at Epicenter 2010 in Dublin on Wednesday, on Noda Time and C# Corner Cases. There are concessionary tickets available, so if you’re on the right landmass, please do come along. Don’t be put off by the fact that I’m speaking – there are some genuinely good speakers too. (Stephen Colebourne will be talking about Joda Time and JSR-310, in a session which I’m personally sad to miss – I’ll be talking about C# at the same time.)

While I’m busy plugging events, I’m also extremely excited about NDC 2010 next week in Oslo. Neal Gafter and Eric Lippert will be doing a C# Puzzler session, Mads Torgersen will be talking about C# 4, I’ll be presenting a wish-list for C# 5, and then all four of us will be doing a Q&A session. Should be heaps of fun. (I’ll also be presenting C# 4’s variance features, and Noda Time again.)

As ever, I’m somewhat late in putting the final touches to all of these talks, so if you’ve got any suggestions for my C# 5 wish-list or any particularly evil corner cases which have caught you out, add them as comments and I’ll try to squeeze ’em in.

12 thoughts on “Epicenter 2010: quick plug and concessionary tickets”

  1. Re C# 5 I’d like some kind of compiler support for string substitutions such that I could use variable names in format strings directly.

    E.g:

    int age = 29; string name = “Tom”;
    buffer.AppendFormat(“Name: {0}, Age: {1}”, name, age);

    Could become:
    buffer.Append(#”Name: {name}, Age: {age}”);

    Like

  2. In no particular order:

    * F# (and thence OcaML et al) style printf statements with compiler verification. No more runtime death in a logging statement.
    I would accept them keeping the existing string.Format() syntax, just give it full compile time support. Could have done with that before they changed TimeSpan in 4.0 :)
    I get that without full type inference this might be painful if not impossible to fully validate.

    * type inference on constructors

    * Full Block Expressions compile time support (i.e. meta programming on statement lambdas, not just expression ones)

    * Much stronger support for immutability:
    I want to be able to mark a variable in a method as immutable and have the compiler check it for me. I want to be able to mark it on a class/struct and likewise have the compiler check (and for this to make all instance fields read only implicitly)

    * First class events in c#, a la f#

    * yield foreach. I hate having to explain this one to people when they blow up nested iterators.

    You might detect a theme of ripping off f# :)

    Like

  3. I know it’s probably too late for you to incorporate this, but I’d really like to see support for const correctness similar to C++. It allows for much cleaner designs when dealing with immutable objects is necessary.

    Like

  4. The C# team has already said that they’re planning to “open up” the compiler, letting it be used as a service to query information about source code. It would be awesome if they decided to go even farther and open it up in another way: by letting people write plugins for it to extend the language. That would obviously be a huge effort to implement, but it could change the standard reply to feature requests from “We’re thinking about it, and there’s a chance it’ll ship in a few years,” to “Implement it yourself!” ;) On a more serious note, it would make it easy, for example, for people to integrate their own static analysis logic into the compile process, make DSLs, and, most importantly, advance the language faster without depending on the C# team’s limited resources.

    Like

  5. Jon,
    I would love to see some sort of AOP right in the language/framework. There are 3rd party libs out there, but it seems that this would be an easy win for the C# team. I also assume that as it would be done at compile time (not post build or run time) it should be snappy!

    +1 for Non-Nullable (Viva spec#)
    +1 for immutability support in general. Eg Compiler should enforce Immutable objects can not themselves contain mutable objects. Possible concurrency improvements compiler checks for im/mutable objects etc.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s