Roslyn (.NET Compiler Platform) As Open Source

I’m really happy that Roslyn has been Open Sourced. But that’s because I trust that it will be an open source project where the teams at Microsoft retain enormous control. I have a couple of stories.

The Conference Conversation

At a bar at a conference last fall I tracked down a guy I respect enormously to convince him to join me in what I perceived at the time would be a battle for a specific language feature. Because of past parallel thinking, I thought this would be an easy sell.

I recall having five reasons that I wanted this feature. I walked through the first four, carefully explaining why I was right. In each case, his response could be summarized as “Anders knows best.” In fairness, he did weigh the issue, and to him the balance of benefit didn’t win over having an expert define the language.

I respect Ander Hejlsberg enormously. I also know from experience that “battling” means ensuring different perspectives are explored over and over in his mind until he either thinks the same thing as I do or doesn’t. I suspect I will never win the XML/JSON literals conversation.

I’m only moderately confident that my putting certain things out there over and over cause Anders and the other language designers to think about issues any more than they already are. They seem to think about your languages all the time. They think fast and fluidly, and with you in mind.

The fifth item my list that night in the conference bar was that there was no other way to accomplish this particular goal. That was the only item that swayed my friend.

The punch line: my friend was right.

The battle I was planning to have is entirely appropriate for the first four of my reasons. It’s just not necessary to involve the language at the intricate behavior layer, because it can be accomplished with parser and editor changes that leverage existing features.

(I’ll discuss the specific issue in another blog post.)

Left or Right Gives Me a Headache

This story is happening as I write this post. I’ve tweeted that maybe you don’t want to know how the sausage is made – how language decisions are made.

If GetCustomer() can return null, to avoid doing this:

var temp = GetCustomer();

string name = (temp == null) ? null : temp.name;

It would be nice to do this:

var temp = GetCustomer()?.name;

But, it turns out to have two possible implementations:

left-associative : x = ((GetCustomer1()?.extraRef)?.name)?.Length

right-associative : x = GetCustomer1()?.(extraRef?.(name?.Length))

Over the last six months, thousands of man hours have gone into trying to decide which is the better approach (before jumping to an opinion, you might want to read the public thread).

People at Microsoft, insiders like MVPs and now the community at large have thought a lot about this problem. Sometimes issues are really, really hard. Subtle and hard enough to make your head hurt.

Sometimes the outcome of a really gnarly issue like this is arbitrary. Sometimes it results in cancelling the feature because the result will be non-intuitive. Sometimes at the end of the discussion, one option has to be vetoed. If one option could win, it was probably not a gnarly issue.

It takes people deeply involved in the languages, trained and collaborating to look for alternative implementations, and subtle issues, and non-obvious breaking changes to manage these gnarly issues. Lucian has seen an issue I didn’t see more times than I can count. It’s his job.

Why This Means Microsoft Has to Stay in Control

I’m confident that Microsoft will remain firmly in control of check-ins to your favorite language compilers. If they don’t we’re dead because of situations like the ones I illustrated.

In the first case, the years of language design teams saying “no, no, no, no, no, no, no” keep the languages comparatively clean. There’s a set of things that have been pushed off because they were hard to do in the old compiler and are now being done. But there is a larger set of things that do not belong in the language because they are parser/preparser/editor issues (I discussed parser/behavior/compiler independence here). It is possible that C# XML and C#/VB JSON literals can even be handled with optional extensions.

The second story illustrates a deeper reason you are happy with Microsoft staying in iron fisted control of compiler check-ins. As a long time MVP I get to see the depth of thinking about dozens of such issues in VB and C# every year. Many issues look simple on the surface, but deep collaborative thinking by the team exposes subtleties that drive one implementation or another. Dozens of issues receive the same kind of “Language Notes” features you see here, here, here, and in many parallel posts.

The Cathedral and the Bazaar

The historic way of creating and supporting the .NET compilers could be likened to building a cathedral (Raymond, Eric S. (2000-09-11). "The Cathedral and the Bazaar" for metaphor). A hierarchy of architects and masons worked together to create a complex result.

Open source has been compared to a bazaar with everyone contributing.

I don’t want the hubbub and chaos of a bazaar. I want the stability and consistency in the longevity of the cathedral. I want the current standards of depth of consideration, and the frequency of “no” to be maintained.

I want to push and prod and play and dance on the edges with parser tweaks and using information from syntactic and semantic trees. I also want the rapid releases of open source.

I want to do this still knowing there is quiet serenity, thick walls and buttresses around the subtleties of runtime behavior and performance.

I still want the language designers that got us this far at the helm. I have no reason to think the open source release of Roslyn changes that.

5 thoughts on “Roslyn (.NET Compiler Platform) As Open Source”

  1. I have too longed for this feature as I do a lot of integration with shipping systems, and all sorts of properties end up being null. I use lambdas to work around it:
    https://gist.github.com/anonymous/47a5fe5b6fe7b6912863

    It looks a little weird, but I got used to it and it has really reduced my NRE bugs:

    var length = GetCustomer1()
    .With(x => x.extraRef)
    .With(x => x.name)
    .With(x => x.Length);

  2. Great post and analogy, Kathleen. I think you are right on with the need for Microsoft to stay firmly in control of checkins. I also think it is extremely valuable to review the Roslyn, er, .NET Compiler Platform source itself to review the relative gnarliness of a proposed change. I asked Anders at Build “Are you *really* going to take pull requests for Roslyn? For real? :)” His response was similar to what the engineers have been saying – bring it on, but expect the same level of rigor and critique that accompany any internal proposal. Sure, Anders is brilliant, and he is one of my heroes. But so is Eric Lippert and somehow the team continued to innovate even after he left. So I’m really confident that if the vetting process is sufficient – and that’s the key in my mind – the process itself – then there should be a healthy and welcome dialog with this open source project that in the past was more logistically challenging. In the next week I will submit a pull request for a VB language feature. I don’t expect it to be accepted at this point, but I do want to get it far enough, so to speak, and that means that it passes all of the tests in the source as well as new tests that will be part of the pull request. Perhaps Lucian or Anders or Anthony will notice a fundamental flaw, either in the idea or in the implementation. No biggie, I can live without it. But then again, maybe it will spark a conversation or get the ball rolling. I’m quite protective of VB, so if that means protecting it from my own ideas, then I’m cool with that :) Nonetheless, seeing that source has been one of the most fascinating moments…ever!

  3. Nulls should propagate. Null meaning an unknown value suggests that null.something would also be null. With this in mind I could simply write:

    var temp = GetCustomer().name;

    and temp would = null

  4. IIRC in Groovy there is a similar syntax for checking nulls.
    But extra parentheses are unnecessary and introduce confusion.
    So instead of this:

    ((GetCustomer1()?.extraRef)?.name)?.Length

    you should simply write this:

    GetCustomer1()?.extraRef?.name?.Length

    Then let the compiler do its magic, figuring out left- or right- sideness, adding null checking and avoiding exceptions.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>