"A Primer on Why the Chronic Suffering of the VB.NET Community is neither Necessary nor a Matter of Expense or Practicality" -- Anthony D. Green

[zspitz]

https://anthonydgreen.net/2020/03/15/a-primer-on-why-the-chronic-suffering-of-the-vb-net-community-is-neither-necessary-nor-a-matter-of-expense-or-practicality/

A must read to understand the current state of VB.NET.

[aarondglover]

Definitely a MUST READ by all in the VB.NET Community and by the executive and those in management positions at Microsoft. Thankyou for taking the time to craft such a well thought out blog post @AnthonyDGreen

I hope this article gets the views and shares that it deserves.

[ericmutta]

@zspitz thanks for sharing this!

@AnthonyDGreen many many thanks for taking the time to write this primer, it has shed light on many issues for me! Some comments follow:

Less than a handful of folks in a team room is enough to radically invert the delays, shortfalls, perception, and “forced tough decisions” narrative many of you have observed in the last few years.

I definitely AGREE with this observation. In fact "less than a handful" is too many: it literally takes just ONE motivated individual to swing the pendulum. I saw this in action when reading about how DotNetNuke switched to C# even though for 8 years it was implemented in VB.NET. One person converted the code to C# and the rest was history. Of course compilers are a lot more complicated, and we would certainly benefit from having more than one person trying to swing the pendulum but it's important for all of us to remember that it doesn't need an army to change the current state of affairs.

We’ve already had engaged potential and actual contributing VB.NET community members....Eric Mutta has tried to make contributions in a number of areas.

This is my favourite line, for obvious selfish reasons :smile: (I am the above mentioned Eric Mutta). I quote it to encourage other members of this community to start making contributions. If you look at my PR's they are all simple documentation fixes. Nothing fancy. At first, the idea of doing a PR was scary. But after doing a few of them (and having a great experience with people like @mairaw and @rpetrusha on the docs team) I now submit fixes to the docs without hesitation, This is an easy way to get started and to get familiar with the people involved. More importantly it allows the people involved to get familiar with YOU, so down the line they are comfortable allowing you to make bigger changes/contributions. :+1:

C# advances the .NET platform....the .NET platform is not and will never be dependent on the VB language (or F#) to make leaps. But if C# is late developing generics, .NET 2.0 doesn’t ship....

I have recognised this reality for a long time and have made peace with it. C# has that unique role which comes with the benefit of being "first" for everything. That's fine. VB also has a unique role that I can describe as simple productivity and much of it comes from the tooling (a simple example is auto-complete behaviour for enums: in C# you have to type the enum name to see the members, in VB the editor shows the members in the list allowing fewer keystrokes to complete them). I have no misgivings with @KathleenDollard's recent announcement that there won't be language changes going forward because the language is pretty solid as it is, but I certainly hope that there will be continued improvements in the tooling and experience of using VB to enable that simple productivity that is at the core of what we all love about VB.

...I was in the beginnings of my current nervous breakdown. My depression was spiking. I was super unhappy where I was...

Thanks for sharing this @AnthonyDGreen, it is a very important and humbling reminder that there human beings behind all of the tools and languages which we out here enjoy (sometimes for FREE in the case of Visual Studio Community edition). I think I speak for everyone when I say THANK YOU to you and the many others for the work you have done and are still doing to give us world-class tools that help us make a living. Your work MAKES A DIFFERENCE :pray:

And just importantly, not having a distinct VB team means…

Just recently @wolvenra asked where's the VB Team? and now we have an answer: there isn't (a dedicated) one! With that in mind, I think the only feature request that matters now is for @KathleenDollard to do what she can to get that dedicated VB team in place :+1:

In closing, and with full understanding that all of this is a human endeavour with real people behind the github handles, I would like to say a special thank you to @KathleenDollard. You walked into an organisation where a 5 minute change can take 5 years to push through (as described in @AnthonyDGreen's article) and miraculously you are still there, no doubt fighting to get something to happen.

You have also faced an increasingly frustrated community that is angry for reasons that are outside your direct control...and miraculously you are still here. Facing the music. Your job is not easy (or fun at this point) and I for one, salute you for your continued dedication :muscle:

[KathleenDollard]

I certainly hope that there will be continued improvements in the tooling and experience of using VB to enable that simple productivity that is at the core of what we all love about VB.

We tried to make it super clear in the blog post that Visual Studio will continue to improve the experience for Visual Basic developers. I stay connected with that team. These ongoing improvements will help Visual Basic developers whether they stay in .NET Framework or move to .NET Core.

Your job is not easy (or fun at this point) and I for one, salute you for your continued dedication

Thank you. I love Visual Basic and Visual Basic developers.

[ericmutta]

@KathleenDollard We tried to make it super clear in the blog post that Visual Studio will continue to improve the experience for Visual Basic developers.

This is welcome news! I currently have 17 bugs filed in the Rosyln repo that relate to the VB experience in Visual Studio. Is it reasonable to expect faster resolution of such tooling issues? (Some of the issues are 3 years old at this point!)

[jmarolf]

And there are approximately 555 C# bugs about the IDE experience as opposed to 34 for VB. Its unclear what faster means in this context. We are not going to commit to timelines on when bugs get resolved. It is reasonable to expect these bugs to get fixed eventually.

[zspitz]

I echo @ericmutta's sentiments of gratitude and appreciation to @AnthonyDGreen for his insightful perspective on what goes on inside Microsoft; and to @KathleenDollard and the Roslyn and VB teams for their work and perseverance under very difficult conditions.

@ericmutta You present DotNetNuke as a single developer swinging the pendulum; I don't think that's quite accurate. It was a single developer who contributed the original C# version, but that alone was not enough to change DotNetNuke. But that developer's work, combined with the demonstration of community interest in a C# source code version, prompted the DotNetNuke team to reevaluate the original language decision and eventually settle on a C#-only code base.

But this serves to underscore Anthony's points. The DotNetNuke team did not write the initial iteration of the C# code base; but it was agile enough to reevaluate its original direction in response to that effort, and to investigate other choices; and once the decision was made to change direction, the team was empowered enough to carry through all the necessary changes and updates that followed from the new direction. Of particular note -- the team was able to coordinate the incorporation of a significant community contribution. I highly doubt any of this could have happened if DotNetNuke was part of a larger organization, and each of the team members had a load of other responsibilities with a vague injunction to "do something for DotNetNuke" on the side.

Yet this is the picture Anthony paints, of the Visual Basic "team" within Microsoft. Is it any wonder that it's been 15 months since the last language design meeting? (And that was a one-off; the last semi-regular meeting was 5 months before that.) Is it any wonder that with all the emphasis on tooling improvements, nothing substantial VB-related ever seems to make its way into the VS release notes? Integrations with other technologies, usage on form factors other than the desktop, samples -- all of this seems to be languishing, even in the face of community interest and a powerful desire to contribute, because there's nobody in the director's chair, coordinating these contributions.

---

How can this picture be changed?

I am not familiar with the internal power structure and politics within Microsoft, but I imagine the ideal solution would be for Microsoft to organize a VB team on the same model as the F# team. However I guess the same bureaucratic inertia that brought us to this point would make this unlikely to happen. But that brings me to the next question:

Is it possible for an external group to fulfill the same function? To serve as custodians and direction-setters for Visual Basic, or for a drop-in replacement/alternative for Visual Basic?

This group would have to overcome the fact that Microsoft really pulls the strings for Visual Basic, and I'm not really sure it could be done.

To a certain extent, these efforts involve working outside of Microsoft, and in direct competition to Microsoft in some sense, But Anthony claims this situation is not the result of willful and malicious decisions to VB and the VB community. If all these efforts were concerted enough, and strong enough, the day may well come when these efforts would spur the bureaucracy at Microsoft to either split off VB into a separate team, or to bring in this outside group under its aegis.

---

As a model of an external group managing a language and ecosystem, consider the Rubberduck VBA project. Microsoft has virtually shut down VBA development; there have been no updates to the language since 2010, and the IDE hasn't been updated since last century. And yet, they have an impressive list of accomplishments:

• using ANTLR to parse VBA
• better navigation, via a member-level code explorer
• unit testing framework
• code inspections
• refactorings

all this with virtually no support or assistance from Microsoft. Perhaps this external group could use Rubberduck VBA as a model.

---

@KathleenDollard @jmarolf I understand if you can neither confirm or deny any of this, but I think I can speak for everyone here when I say that whatever input you can safely provide would be greatly appreciated.

[zspitz]

Ping @WolvenRA

[WolvenRA]

@zspitz Hey! BIG THANKS for posting the link to Anthony's blog post. I would STRONGLY encourage everyone to read that post. It is quite enlightening and gave me hope that the "current situation" for VB.Net can be changed. I apologize for double posting this, but based on Anthony's post...

Considering that the primary problem is the "bureaucracy" at MS rather than any real "malice" toward VB (supposedly) my question is, what can we as a community do to recreate the separate (from C#), agile, empowered, autonomous, passionate, and dedicated, VB.Net focused team at MS that Anthony describes?

I can understand that the current MS VB team may not have the ability, influence, political strength, etc. within MS to create the type of VB team Anthony describes, but WE the community aren't limited to following the chain of command or endangering our jobs (since we don't work for MS). The worldwide community (all VB.Net developers, software companies and businesses using VB based software) is HUGE! If we can get even a small percentage of that community to unite behind a common cause, I believe we can get the attention of the top executives at Microsoft... and hopefully, motivate them to create the VB.Net team we all want.

[VBAndCs]

@KathleenDollard @jmarolf I said a year ago that MS should help VB community to take over! Now it is more certain that this is a must. Please help us evolve our beloved language on our own. MS will benefit of this, since it will continue to sell VS.NET to VB.NET customers. I asked repeatably for help to understand the structure of the one_million_lines_of_code VB.NET compiler. @AnthonyDGreen never completed beyond hist first part about VB.NET compiler anatomy. There is no resources about this. I read generally about compilers and some tutorials about C# compiler and VS extensions, but this is not enough. If you invested in training us in the last three years, the outcome could have changed dramatically! It is not too late. MS owes this to the community.

[zspitz]

Quote:

If we can get even a small percentage of that community to unite behind a common cause, I believe we can get the attention of the top executives at Microsoft... and hopefully, motivate them to create the VB.Net team we all want.

My understanding, based on the blog post, is that the issue is not getting developers to follow the cause; the problem is that there is nobody whose primary focus is advancing VB. A small group of such people (Anthony puts the number at 3-5 developers) IMO needs to have 1) the time+resources to devote almost exclusively to this, and not to be pulled off for other things; 2) the authority and ability to push changes beneficial to VB in other areas, and 3) accountability to the community.

With such a nucleus, there would be someone to turn to in order to coordinate community contributions; they would be responsible for identifying important areas, keeping after maintainers, and picking up the slack for areas nobody wants to contribute,

If such a group were to form within Microsoft, it wouldn't have to fight to establish its authority to push changes on other teams; probably a good thing. But an external group, while not waiting on Microsoft, would face an uphill battle for the VB market share currently controlled (at least on paper) by Microsoft.

I think VB advancement can be grouped into a few areas:

• language design
• compiler implementation
• tooling (includes Visual Studio, perhaps via a custom extension; and possibly an LSP a la OmniSharp)
• documentation
• templates and samples

I think this VB "working group" would have to provide compelling value in one or more of these areas in order to be able to get anywhere.

[WolvenRA]

@zspitz I think we're saying the same thing. I'm talking about getting a "united community" to push MS to separate\create the VB team into its own autonomous group... like the F# team.

[zspitz]

@WolvenRA Or the Typescript team. Can you imagine VB.NET on a monthly or bimonthly release cadence?

[Happypig375]

@zspitz A release cadence based on Visual Studio minor releases would be more reasonable.

[zspitz]

@Happypig375 Would it be possible to detach it completely from the VS releases? Every so often VS would notify you that there has been an update to the VB extension. I'm assuming that's how it works with F#.

But AFAICT since the current architecture bundles C# and VB together, and C# is inevitably tied to VS releases, it would be necessary to develop a fork of Roslyn into such an extension.

[Happypig375]

@zspitz Take a look: https://github.com/dotnet/fsharp/releases

[salelele]

@AnthonyDGreen Thank you for your post. At least we begin to understand and appreciate some of the gyrations with regard to product development and product teams that are happening at Microsoft.

When Ms decided to delete Visual FoxPro a few years ago, the community stepped up and began developing open source add-on and enhancements to the product, even adding web development. Perhaps the Visual Basic community members need to step up now and develop add on products especially in those areas where the team may not have the necessary time resources to work on their own.

With some guidance we can work under their supervision and transparently here. Community could develop extensions to enable mobile development, and other such tools as the VB developer needs to create modern apps. How Extensible VB will be on .Net 5 will also be key.

[pricerc]

And so it seems to me that with the comment left by @KathleenDollard recently over at Add VB.NET Support to .Net Core 3 WPF/Windows Forms Projects, there is tacit consent from Microsoft for a community-driven fork of VB.

Kathleen Dollard [MSFT] 13 hours ago To clarify. We aren't going to get upset about forks. We also don't have plans to accept language features.

and

Kathleen Dollard [MSFT] 13 hours ago @Jeff Bowman yes, I was replying to @Vinícius Werneck's comment. We don't have plans to accept new language features, including those by external contributors.

Not that 'consent' is strictly needed for an open-source project, but implied by the statement is that Microsoft will not get in the way of such an effort. Since it seems to me that the biggest problem VB has had since @AnthonyDGreen left is Microsoft getting in the way of progress with the language, there is an opening for someone(s) with the right skills and resources to take a lead on developing a community-driven VB fork.

[zspitz]

I think there is another question that needs to be answered. What does VB.NET gain from having its development tied to C#'s via the Roslyn compiler? Feature parity with C# is no longer a stated goal. Shared analyzers? Doesn't seem to work out very well in practice. Performance benefits? A fork of the compiler should be able to incorporate such changes.

That inevitably leads to: Would there be value in creating a fork of the Roslyn compiler which only handles VB.NET? Would it be simpler to work with and understand?

[pricerc]

Would there be value in creating a fork of the Roslyn compiler which only handles VB.NET? Would it be simpler to work with and understand?

I would have thought this would be step one. But I thought the VB compiler was already written in VB?

An awful lot of work I do is refactoring old code, which almost always starts with getting rid of all the things that are no longer needed.

[VBAndCs]

But I thought the VB compiler was already written in VB

True, but most of it depends on common code written in C#. When I wrote HTML completion provider for XML literals, based on the vb version of the XML document comment completion provider, I had to convert some internal C# classes to VB to separate the code from Roslyn. So, It is hard to extract the VB compiler from Roslyn.

[VBAndCs]

In fact, adding new syntax to the VB compiler is not the problem. The Real problem it integrating it with VS (syntax checking, debugging, analysers, ... etc). Worest, VB is left out of all new techs (ASP.NET Core, Blazor, EF core, Xamarin, MAUI, winUI... etc). So, we need many teams to integrate VB with all these techs! The only way to make this happen, is to make big companies depending on VB.NET fund such forks. This may cost them less than converting there code bases to C#.

[bandleader]

@zspitz AFAIK it wouldn't be helpful to try and separate the VB compiler out of Roslyn. Although you're right that Roslyn is a hard compiler project to get started with (see @KathleenDollard's comments here) it would be even harder to separate it out. If the community wants to fork Roslyn in order to add features to VB, nothing is technically "standing in its way;" but practically, what is standing in the way of this happening is:

1. Working together: As mentioned, it's not easy to just jump in to the Roslyn source and begin adding features (I've tried, and I've written a compiler). Whoever does so would need to know that the Roslyn team has our backs and can give us some person-hours here and there to help us with getting familiar, etc. Right now, the response from the Roslyn team is mostly non-existent (and occasionally hostile).
2. Inclusion in releases and the .NET ecosystem: We would want to know that the new language features would be integrated into Visual Studio (whether integrated fully into Roslyn or hidden behind a version flag), because without mass-market reach, the project is not feasible. Not to mention that it would break with every VS release and be unsupported in new MS technologies, etc., like VB is already starting to be. However right now, @KathleenDollard confirmed that

   We don't have plans to accept new language features, including those by external contributors.

(That doesn't preclude remaining a fork but one with inclusion in VS on par with F# -- but MS will not allow that any more than allowing the changes into Roslyn behind a version flag; there isn't much difference other than duplicated binaries.)

[bandleader]

Also @KathleenDollard, since it's been a few months since your last comment here, can we ask if there's any update?

[cristianlt23]

@zspitz obrigado por compartilhar isso!

@AnthonyDGreen muito obrigado por dedicar um tempo para escrever esta cartilha, ela esclareceu muitas questões para mim! Alguns comentários a seguir:

Menos de um punhado de pessoas em uma sala de equipe é suficiente para inverter radicalmente os atrasos, as falhas, a percepção e a narrativa de "decisões difíceis forçadas" que muitos de vocês observaram nos últimos anos.

Eu definitivamente concordo com esta observação. De fato, "menos que um punhado" é demais: literalmente, é preciso apenas UM indivíduo motivado para balançar o pêndulo. Eu vi isso em ação ao ler sobre como o DotNetNuke mudou para C # , embora por 8 anos ele tenha sido implementado no VB.NET. Uma pessoa converteu o código em C # e o resto foi histórico . É claro que os compiladores são muito mais complicados, e certamente nos beneficiaríamos de ter mais de uma pessoa tentando balançar o pêndulo, mas é importante para todos nós lembrar que não é necessário um exército para mudar o estado atual.

Já contratamos membros da comunidade VB.NET potenciais e efetivos ... Eric Mutta tentou fazer contribuições em várias áreas.

Esta é minha frase favorita, por óbvias razões egoístas 😄(Eu sou o Eric Mutta acima mencionado). Cito-o para incentivar outros membros desta comunidade a começar a fazer contribuições. Se você olhar para os meus PRs, todos são simples correções de documentação. Nada chique. No começo, a ideia de fazer um PR era assustadora. Mas, depois de fazer algumas delas (e ter uma ótima experiência com pessoas como @mairaw e @rpetrusha na equipe de documentos), agora envio correções para os documentos sem hesitação. Essa é uma maneira fácil de começar e se familiarizar com o pessoas envolvidas. Mais importante ainda, permite que as pessoas envolvidas se familiarizem com VOCÊ; portanto, elas são confortáveis, permitindo que você faça alterações / contribuições maiores. 👍

O C # avança a plataforma .NET .... a plataforma .NET não é e nunca será dependente da linguagem VB (ou F #) para dar saltos. Mas se o C # atrasar o desenvolvimento de genéricos, o .NET 2.0 não será lançado ....

Reconheço essa realidade há muito tempo e fiz as pazes com ela. O C # tem esse papel único que traz o benefício de ser o "primeiro" de tudo. Isso é bom. O VB também tem um papel único que eu posso descrever como produtividade simples e grande parte dela provém das ferramentas (um exemplo simples é o comportamento de preenchimento automático para enumerações: em C #, você deve digitar o nome da enumeração para ver os membros, em VB o O editor mostra os membros da lista, permitindo que menos pressionamentos de teclas sejam concluídos). Não tenho dúvidas com o recente anúncio do @KathleenDollard de que não haverá mudanças no idioma daqui para frente porque o idioma é bastante sólido, mas certamente espero que haja melhorias contínuas nas ferramentas e na experiência dousando o VB para habilitar a produtividade simples que está no cerne do que todos gostamos no VB.

... Eu estava no começo do meu atual colapso nervoso. Minha depressão estava aumentando. Eu estava super infeliz onde estava ...

Obrigado por compartilhar este @AnthonyDGreen , é um lembrete muito importante e humilhante de que existem seres humanos por trás de todas as ferramentas e linguagens de que desfrutamos aqui (às vezes de graça no caso da edição da Comunidade Visual Studio). Acho que falo por todos quando digo OBRIGADO a você e a muitos outros pelo trabalho que você fez e ainda está fazendo para nos dar ferramentas de classe mundial que nos ajudam a ganhar a vida. Seu trabalho FAZ DIFERENÇA🙏

E, o que é mais importante, não ter uma equipe VB distinta significa ...

Recentemente, o @WolvenRA perguntou onde está a equipe VB? e agora temos uma resposta: não existe (dedicada)! Com isso em mente, acho que a única solicitação de recurso que importa agora é que a @KathleenDollard faça o possível para colocar a equipe VB dedicada no lugar👍

Para concluir, e com total entendimento de que tudo isso é um esforço humano com pessoas reais por trás das alças do github, gostaria de agradecer especialmente a @KathleenDollard . Você entrou em uma organização em que uma mudança de 5 minutos pode levar 5 anos para avançar (como descrito no artigo de @AnthonyDGreen ) e milagrosamente você ainda está lá , sem dúvida lutando para que algo aconteça.

Você também enfrentou uma comunidade cada vez mais frustrada e irritada por razões que estão fora do seu controle direto ... e milagrosamente você ainda está aqui. De frente para a música. Seu trabalho não é fácil (ou divertido neste momento) e eu, por exemplo, saúdo você por sua dedicação contínua 💪

All right? it is also worth thinking about a financial contribution by companies and users of VB.net, perhaps most cannot contribute with technical knowledge, but can contribute financially.

The community that creates a beautiful website for knowledge, courses, news and new directions on VB.net is sure that there will be many subscribers.