Part II: A Direct Response

Inappropriate

For starters, I just want to say that this statement on .NET 5.0 seems ill-timed. The nature of the message contrasts in a very unflattering way with the kind of reassuring supportive messaging other companies I interact with have been putting out during this time of worldwide crisis. I can only hope that this timing is a coincidence and not any intentional decision to take advantage of a social media trend and a news media cycle currently preoccupied with an admittedly more important global pandemic.

Disingenuous

Next, I want to address some disingenuous language you’ve sprinkled in here and some other language not used but evoked here which I’ve heard floated in the last year or two in places, testing out reactions.

The idea that Visual Basic’s “stability” is “valued”. Well, of course! Everybody enjoys stability. It’s kind of part of the Microsoft brand. What exactly is the implication here, that … if we add one more feature to VB.NET… the users will rebel and… leave? To C# (and you desperately want to prevent that)? To Java? What? They’ll stop upgrading to VS for fear of new features creeping in? And at a greater rate than those who won’t upgrade because they have no reason to? They’ll rebel more than they do when you tell them you’re not evolving the language anymore? How did you do the math on that? Was there a survey!?

“The most important thing is that it keeps doing what it’s been doing”

Was instability on the table? How does this contrast with the other .NET languages? Is that the new C# tagline? “C# – breaking stuff, all the time”. “F# – too bleeding edge for compat; the F stands for free-and-loose”. It’s a meaningless thing to say because for its entire life since 2002 the evolution of VB.NET has been concerned with stability and compatibility, like all of the .NET languages.

This is like when discussing hiring from underrepresented groups someone says “But of course the most important thing is that they’re qualified!”. It’s disingenuous. It prefaces or excuses the inexcusable by putting it next to a statement that’s universally considered sound and positive but the impacts of the thought next to it are anything but sound and positive.

This is made more inappropriate by the fact that, as I point out here, the .NET Team (no quotes) is generally not part of the VB.NET community. You, a group of people not in my ingroup, telling me what matters to me and then using that thing you told me I value to discount my opinion is condescending and inappropriate. It would be so in every other context and it’s still so here.

“People aren’t clamoring for new features”

You have numerous channels for user feedback where currently and since its inception, members of the VB community have and do communicate constantly their desire for evolution in language and tooling because that is also valued.

Again, it’s like someone saying “But the biggest contributor to carbon emissions is going to be the industrialization of China and India, so nothing we do matters anyway”. They’re not putting that cherry-picked fact forth because of their genuine heartfelt commitment to disseminating objective truth but because that particular truth doesn’t ask anything of them today. It allows them to keep doing what they’re already doing. And this narrative you’ve constructed about stability and compatibility is an equally disingenuous notion that doesn’t ask anything of you.

More Inappropriate

If you look at the F# language suggestions repo there’s a section on the design process. And in the section on new features it says this:

“Stability is a virtue”

Stability is valued elsewhere and yet F# marches on. They didn’t need to make a sweeping statement sandwiched in the middle of a post on how “F# planned to be in next release of Visual Studio”. They just keep the language stable because that’s leadership.

I worked on VB.NET for 8 years. I never needed to make a sweeping statement about evolution in general to be responsible, keep it stable, or compatible. I’ve personally argued against or killed plenty of unnecessary features that were only proposed because that feature was going into C# but just didn’t make sense in VB, wasn’t needed, or broke compat, etc.:

  • Expression-bodied properties & methods?
    Stylistically inconsistent, waste of time; long tail of follow-up asks to make it consistent.
  • Primary constructors?
    Wrong design for VB.
  • Deconstruction statements?
    Too early to tell given named tuple elements.
  • Declaration expressions?
    Didn’t fit.
  • Async void?
    Didn’t need it, tried to kill it and failed.

So, for instance, when thinking about “evolving”, what about a feature like Await being allowed in Catch & Finally blocks? It’s a feature I know customers clamored about when it was cut from VS2015 due to the unplanned schedule contraction detailed here. Logically, it was an approved and desired feature that should have rolled over to the next release but didn’t make it and should have rolled over to the next release after that and still hasn’t made it.

If right now you’re thinking “Oh! Forgot/didn’t know about that”, it indicates to me that you’re probably not the body who should be making sweeping statements about the language’s evolution.

When the implementation of ref returning methods was too invasive and incoherent with the VB design I proposed a tailored subset and then accounted for that decision publicly. I signed my name. As I did on every feature request on Connect, UserVoice, or GitHub that I’ve ever responded to across hundreds of customer interactions. I know Mads has been similarly accountable for C# and Don accounts for F#.

The “The .NET Team” attribution on this post illustrates precisely the lack of accountability when there isn’t a VB Team that I describe here. Who is “The .NET Team”? If I have questions, who do I reach out to? If we’re at a conference do I just walk up to anybody and start talking? If this decision turns out to be really bad, who is held accountable for it? Do we just get a whole new “The .NET Team”? Like, all of you?

I suppose that it’s consolation that you didn’t scapegoat Kathleen on this one. I watched her tirelessly advocate for VB, including thoughtful language evolution for 8 years. We don’t always agree but she’s been fighting this fight longer than I have. We know how long she’s been at Microsoft and I’ve seen what happens when newer PMs take the fall for other people’s decisions so I’m glad at least that you didn’t drag her name through this mud pit you’ve created.

You should be able to articulate the principles, the design patterns, and the style of the Visual Basic .NET and how any potential new feature caused by anything either fits or doesn’t fit into that style, or is incompatible. And if don’t feel capable of that then you definitely aren’t the body that should be making sweeping statements about the language’s values and evolution.

You’ve presented this blurb couched in language which suggest stewardship with intention and thought when it precisely promises the absence of thought and the absence of intention. This post is illustrative of precisely why leadership of an open source language from people outside of that language community is wrong.

More Disingenuous

But let’s go back to my example of Await in Catch/Finally; a feature which illustrates that this statement isn’t the result of a shift in thinking but attempt to normalize or rationalize a system which is already horribly broken.

It’s a feature we (because I was there) costed at about a week. It had been done for C# already but had to be cut in VB due to a schedule change. It’s a known quantity of low cost that adds no new syntax to the language, probably has no IDE work, and actually makes the language more consistent. This would otherwise be the least controversial addition to the language. This lowest hanging fruit has been out of reach for 5 years.

Now let’s take something that was done. In VS2017 Visual Basic, like C#, received updates after RTM. One such update was non-trailing named arguments. A great feature that makes VB code more descriptive. The problem is that as an out-of-band feature, in order to use it you had to update the project language version to 15.5. No UI for doing that. No dropdown in the project properties.

So, you’ve somehow worked yourself into a situation where you’ve not only been unable to deliver small, well-understood features, with no new syntax or conceptual burden, that were already agreed upon and promised, but you’re also unable to ship any UI to enable customers to use the new features you have added. Which is an indictment of your process. The only thing that’s changed here is whereas before you were unable or unwilling to account for missing features, now you don’t have to.

Continuing on this thread, in C# there was a quick-fix (a feature pioneered in VB) to update the language version from within the editor. It made 150% sense for VB, but required an API change within the bowels of Visual Studio to pass some information from one service to another in order to make that fix possible. But the bureaucracy made even that impossible. The only option for VB users was to unload the project and manually modify their project file: the most un-VB experience ever.

And in VS2019 you cut temporary “zero-impact” projects, a feature that QuickBasic, VB6, and VBA all have and most other Microsoft products have an analog to. I open word, I can start drafting in a new doc without saving to a particular location. I can even work on VBA macros without saving. Same with Excel, PowerPoint, Notepad, Paint, etc. It’s an established paradigm.

Speaking directly to my point about whether a C# body can understand, respect, and defend VB experiences: this feature was specifically added back to VS2005 after massive feedback from VB users that creating “ConsoleApplication238” was a big takeback from VB6. It was available to C# for years but off by default and on by default under the VB profile, including the very successful VB Express Edition.

I literally use this feature every day: Spinning up temporary projects to help other VB users on the Internet. Do you know how many throwaway projects one makes in a day answering questions on VB Facebook groups? VS2019 literally broke one of my critical workflows and you weren’t even slightly apologetic. You didn’t care about stability or compatibility or the spirit of VB then. But what you probably cared about was NuGet and that zero-impact projects didn’t support it, and you didn’t want to do the work to make that happen, and so dismantling a core VB experience of 12 years was an easy decision for you.

So, here’s my problem and why this post lacks credibility as any genuine stewardship from the thoughtful “good guys” you try so hard to present yourself as with these crafted words. It is evident that you don’t truly understand, respect, or care about VB’s unique qualities or vantage point. You only use its uniqueness and its style as a bludgeon weaponized against its community: a nebulous reason to do or not do whatever you want. Which, again, is an indictment of a process where C# developers lead the VB language.

You can’t (for systemic reasons) or don’t want (because you’re not VB developers) to work on VB. I also don’t want you working on VB. It’s demonstrably harmful and it was harmful long before this statement. Far more harmful than whatever “stability” or “compatibility” boogeymen you’re protecting us from. But there is a working model for liberating yourself from that responsibility that doesn’t involve hurting me. I want you to be only as involved and concerned with VB as you are and have always been with F# and through the same means. I’m sure they equally thank you for that level of autonomy.

Conclusion

“The .NET Team” is effectively a body of C# developers. C# developers should not be making sweeping declarations on the future of VB.NET because none of them have to live with those decisions. You’ve attempted to present a narrative of stewardship under the color of legitimacy but your statement on “Visual Basic support planned for .NET 5.0” is replete with questionable timing, questionable reasoning, questionable plans, from a questionable source with questionable history and just a general display of questionable judgement. The current system is broken and it’s failed. And your statement is not the solution to that brokenness, it’s just the latest symptom.

When you’re doing something righteous, well-reasoned, and that reflects honorably on you and your company, no one will be suspicious of why you published it in the middle of a global pandemic, and you’ll feel confident enough in it to sign your name.

-Anthony D. Green

Preface | Part I | Part II | Part III | Part IV | Part V: An Open Letter to Satya Nadella

Comments have been disabled for this post. If you have feedback on this topic specifically it belongs here, on the .NET Blog.