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.