14 Top Features of Visual Basic 14: The Q&A
Leading off the feature in the January issue of MSDN Magazine is Lucian Wischik’s fantastic look at Visual Basic .NET 14. As Wischik writes, the newest version of Visual Basic has been written from the ground up, in Visual Basic no less, to support a raft of compelling new features, functions and capabilities. To determine which features best merit mention in the article, Wischik decided to poll members of the Visual Basic Language Design Team. I asked Wischik about his experience writing the article, and what the latest version of Visual Basic means for the beloved programming language.
MD: I’m fascinated by the fact that Visual Basic is now open source. As a member of the team, what’s it like going from traditional program manager to public “steward of the language?” How does your job change?
LW: Most things haven't changed: our job has always been to serve our users, listen to what they ask for, and figure out the best cleanest way to satisfy their underlying needs. We've always written code that we're proud of, and come up with language designs that we're proud of in the end.
What's changed so far is buried in that phrase "in the end." Practical language design is a messy process that takes lots of eyeballs, lots of diverse opinions, lots of use-cases, and lots of iterations. We've been able to immerse ourselves in the Roslyn forums and get more eyeballs, opinions and use-cases more quickly than we did before, and so we've been able to converge on the final language designs quicker and with higher confidence.
In practical terms, the change is minor. It means that we discuss our language design meeting notes in the Roslyn forums, rather than just in internal email threads and hallway chats. In personal terms, we were worried about having people see how the "language-design sausage" is made. Would they be happy to participate, or become vegetarians? I'm happy to say the former!
We've not yet reached the end of our open-source journey. That's still to come. We look forward to a workflow more like that of TypeScript and F# on GitHub. We plan to push the boundaries next year with things like public Web casts of our language design meetings.
MD: How long has VB been officially open source and what kind of interactions are you seeing from the community at this point?
LW: Anders Hejlsberg clicked the button to open-source VB and C# live on stage at BUILD 2014 in April. It was an amazing moment. "The click that shook the world," wrote one person. "Microsoft's crown jewels are now open-source," wrote another. You can imagine how delighted we were by the reception.
Everyone uses VB and C# all the time, so we've had lots of interactions about parts of the language that people want changed. But few people write compilers as their day jobs, so there have been proportionately fewer code contributions to the compilers themselves. That's fair enough!
MD: The refactoring and analyzer functionality you write about, are those a product of the Project Roslyn effort? And are these capabilities that are enabled by the ground-up rework of the VB compiler?
LW: Yes, they were a primary objective of our rework. It would have been impossible to graft them onto the old codebase.
I think they are visionary features. In college computer science classes, we're taught that a compiler is a "black box" that takes in source code and spits out a binary. But what we've come to understand over the past two decades is that a compiler also exists to serve the IDE, to serve the interactive experience of writing code—and we've been able to embody that cleanly in the Roslyn codebase and its analyzers.
MD: Can you describe the task involved in migrating VB from its C++ roots to VB? How long did it take to rebuild the programming language from scratch as you describe, and what were some of the toughest obstacles you had to face to get there?
LW: After you've spent a decade building up your old codebase, it's a programmer's dream to be able to re-architect from scratch in the light of what you've learned—and management's nightmare. That's because you're investing a lot of developer-years just to regain the functionality you already had, even before you start to add any new end-user value. There's also the risk that you might fail to reproduce all of the quirks or bugs of the old codebase that people might inadvertently depend upon.
I'm glad that our management had the vision to let us do this rewrite. It's the strongest vote of confidence a business can make. We believe our product has such a strong future in the decades to come, that we can invest all our developer-years now to prepare for that future.
I asked Dustin Campbell for his opinion. He's been involved in the rewrite from day one back in March 2010, over four years ago. Dustin observes that Visual Basic is an immensely complex language, more so than C#. It has collected so many features over the years. There was just a large volume of work to get done! And the IDE experience for coding in VB had been carefully tuned over the past decade and users have built up great muscle-memory. We had to work hard to replicate that, and modernize it at the same time.
One of the most nail-biting moments was in December 2013 when we flipped the so-called "Big Switch." This was the moment when our entire division switched to using the new compilers—Visual Studio itself was now being built using the new compilers, and all the developers in our division were using them too. And it worked!
MD: Are you afraid that C++ developers will come after you for writing that moving off C++ to VB made VB14 considerably faster? Those sound like fightin’ words.
LW: I'm not here to fight! What makes code fast is picking the right data-structures and algorithms for the job at hand. We had the opportunity to completely re-architect, picking better data-structures and algorithms in light of our experience. We could have gotten the same speed up if we'd re-architected in C++.
Paradoxically, one of the best changes was to build our compiler out of immutable data-structures. It sounds strange--after all, the act of typing amounts to mutating the text in the editor buffer. In the old codebase, with each keystroke, we'd mutate the syntax tree that the IDE held in memory. In the new codebase, we instead generate a fresh immutable syntax tree of your entire project, sharing as much as possible with previous syntax tree. Immutability lets us share vastly more than we ever could before.
VB and C# have one particular language feature that helped with performance—the async/await keywords. Thanks to these keywords, and thanks to immutable data-structures, we were better able to use multiple CPU cores. But async/await are coming to C++ as well, and are present in experimental form in Visual Studio 2015.
Comments
Anonymous
January 13, 2015
Good interview. Looking forward to the release of VS2015 so we can then open up the languages for more substantive pull requests. The Roslyn forums have been great for discussing new features important to the language teams but a lot of good ideas from the community have to wait until the initial rollout.Anonymous
January 29, 2015
Still no sign of Microsoft open sourcing the VB6 programming language. Just what do Microsoft have against VB6 and VBA programming ?Anonymous
March 02, 2015
Still nothing from Microsoft about open sourcing VB6. Why do Microsoft open source other software but don't even reply to the call to open source VB6 programming ?Anonymous
April 02, 2015
No commenting on articles yet ? How long does it take to add back the comments facility ?Anonymous
April 10, 2016
Microsoft say "Windows is committed to compatibility. The Windows compatibility team has been looking at user telemetry and reacting to feedback from Windows Insiders to ensure that existing apps work well with Windows 10. Windows 10 is designed to run Windows 8.1 and Windows Phone 8.1 software programs. And yes, everyone’s favorite VB6 Runtime will continue to work, too."Microsoft support VB6 on Windows 7, 8 and 10 for the lifetime of the operating system (so until at least 2025 for Windows 10). The support statement is here: " https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx "