I am so excited about a future release of .NET and Visual Studio!
I went to the MVP Summit and I’m cool with the fact that I’m under NDA until anything new that might be happening is discussed publically by Microsoft.
But, I also really understand the confusion and frustration across our segment of the industry. Microsoft going dark has often meant a product was in trouble. So, are .NET, Visual Studio and C#/VB in trouble?
The simple answer is – no, there are not in trouble. But a future release is a complex and tricky release. Below are the dots – you connect them. We MVPs are so respectful of NDA that we often don’t say what we can say because we aren’t 100% sure that we can say it. These dots aren’t NDA.
If you’re in the “I trust Microsoft camp,” that’s great. But the reason you can trust Microsoft is that there are a few thousand people under NDA with Microsoft or pushing the boundaries in Open Source and other companies that nudge Microsoft back to the straight and narrow. Imagine a gauntlet that the tools you use to make your living have to go through.
I’ve been one of the voices in that gauntlet for a long time, and I’m incredibly passionate about the future of .NET/Visual Studio. I do try to be polite, but, well, I did go off in the hallway on one unsuspecting Softie when he told me that his team (which is not one I watch closely) was doing something incredibly stupid – sorry about that and I hope his boss explained me to him.
Anyway, I said I’d give you dots.
The first dot is that you really do care. It’s your future.
The second dot is that there are thousands of really smart people helping Microsoft and hundreds within Microsoft that have been working on a future version for a couple of years. There’s a reason I used the hash tag #teamsworkinghardbeingsmart.
The third dot is that Microsoft is working on new compilers for C# and VB. The only thing that should terrify you more than new compilers is the state of the current compilers. They were started about 15 years ago – before .NET, before agile, before common unit testing, before modern decoupling strategies, before the current folks were on the teams, before many of them graduated high school… Sure the old compilers work, sure there are millions of tests, but what do you think changing those compilers involves?
The fourth dot is that the new compilers can’t be significantly slower. Who do you guess has some of the largest .NET programs on the planet? And does Microsoft care about that? Increasing compile times significantly isn’t an option.
The fifth dot is the new compilers can’t break legacy code. Or at least not much and only when we’re warned. Fail this, and nothing else matters.
The sixth dot is that compilers now drive editors via compiler services. If customers hate that version Visual Studio, they won’t use the new compilers.
The seventh dot is that Microsoft is doing something brand new with compilers. I know it sounds geeky and like a big yawn to say that the syntactic trees and semantic trees will be visible and probably mutable (although there is no reason they need to be mutable in the first version). But this changes everything. Assuming we get a good way to communicate between your code and the compilers (a different post topic) this opens the door to removing almost every stupid aspect of code you write today. INotifyPropertyChanged is the poster-child, the tip of the iceberg, and I think the least interesting of what you are bound to see.
The eighth dot is that putting new compilers in place and pulling it all together is really hard. The compiler API has to come before the compiler, before Visual Studio and language changes. But surely they will screw up something in the API that they’ll find as they build the compiler and then they have to change the API, which also affects language services. And surely creating languages services for Visual Studio will uncover things that could be done better in the compiler or services API. If something goes wrong the whole house of cards falls down.
The ninth dot is that a good compiler, an open compiler API, and better language services immediately opens new doors. I’ll tell you in another post what I’m doing with Roslyn right now (still deciding whether to discuss with old API or wait for the next API release to talk about my own stuff). On the languages front, see this post on Mads Torgersen’s NDC talk. On other fronts, what can Visual Studio, Open Source and third parties build with compiler services not tacked on as a way to make VB do what it used to do, and C# catch up with VB and Eclipse?
The eleventh dot is that Microsoft needs to tell you a comprehensible story. Since Mads has announced some stuff on languages, I’ll stick to that space. Dribbling out monadic null checking and static type using statements would just muddy the water about what’s important. The compilers, while they won’t affect your code, are the big story on the languages front. But the rest of this stuff? That looks like nice little additions to the language. When you see a coherent story, you’ll be able to mentally do your “I care, I don’t care” checklist. Of course I want Microsoft to release information faster so I can talk about it, but I understand why they want to make it sane for all of us.
The twelfth dot you’re looking for is “When will this happen?” I’ve carefully avoided the words “next” and “VNext” because Microsoft has carefully avoided committing to anything I’m talking about here being in the next version. But I was sent this as a verbatim copy of one of Mads’ NDC slides “The whole C# and VB team is working on it, VS itself is compiled with the Roslyn compiler, Everyone on the team uses the Roslyn IDE.”
The thirteenth dot is that I’m happy. I’m excited about a future release of the entire .NET/Visual Studio family. Read into my happiness all you want and I think there will be boatloads to talk about soon.