dotnet / vblang

The home for design of the Visual Basic .NET programming language and runtime library.
290 stars 64 forks source link

Help keep VB.Net a First Class Language on .Net 5 #496

Open WolvenRA opened 4 years ago

WolvenRA commented 4 years ago

This isn't a feature request, it's a message to all the VB.Net programmers here.

I have an idea to help keep VB.Net "co-equal" with C#. If you send me an email at Blog@Wolven.net I will reply with the details of my idea.

rskar-git commented 4 years ago

@WolvenRA, whatever big plan you may have in mind, may I offer some observations?

(@tverweij and @paul1956, you may want to listen in, since you as well as @WolvenRA run businesses on VB.)

Cutting to the chase (executive summary): You need to boost the "dogfooding" aspect of VB governance with buy-in from Microsoft; you will likely need to somehow build a bloc (or consortium) which can provide substantial resources towards VB work, and have it be substantial enough that it can materially participate in the .NET Foundation Technical Steering Group (or whatever other work-able arrangement - https://dotnetfoundation.org/about). I think a world-wide dues-paying consortium of businesses that already use VB.NET and also strongly desire its continuing enhancements should be a natural and most-doable thing for even a small group of business-owners to start. Perhaps one could leverage crowd-sourcing towards this end (e.g. https://www.patreon.com/ or https://www.kickstarter.com/). The main idea is to first explore what may be already possible and do-able via the DotNet Foundation as it is today.

Otherwise, any other plan that is a go-it-alone or another-fork of VB may prove expensive/exhausting, and is unlikely to improve the share of hearts-and-minds among programmers and businesses. "Visual Basic" is trade-marked and not submitted to any standards group, which are impediments for promulgation (let alone commercialization) of alternatives under that name (not to mention any other IP issues you may need to research and resolve). At best, you can certainly make your own customized "VB" for your own internal purposes (Roslyn is under MIT License - https://github.com/dotnet/roslyn/blob/master/License.txt), but unless one is also seriously interested in getting into the programming language business (under a new marketing name for it), that will not improve matters for VB.NET proper.


The programming language business isn't what it used to be. Microsoft may have had its start in selling languages, and then branching out into other kinds of software and operating systems etc., but that is so over forty years ago. Whatever programming language products that are still on sale today, they tend to be either for niche markets or specialized "tooling" enhancements for paying customers. Heck, maybe about 2007 or earlier, Bjarne Stroustrup (creator of C++) had said, "There are only two kinds of languages: the ones people complain about and the ones nobody uses." The meaning of which is that even warty/imperfect/awkward-to-use languages can persist on the strengths of their workability and relative ubiquity.

Anyway, what I'm getting at is that today's successful programming languages have at their heart one main thing: "dogfooding" (https://en.wikipedia.org/wiki/Eating_your_own_dog_food, https://www.techopedia.com/definition/30784/dogfooding, https://blog.codinghorror.com/the-ultimate-dogfooding-story/, https://wiki.c2.com/?DogFood).

In a nutshell, a programming language in today's world gets started, maintained, and enhanced, because the owner/steward/keeper of it really needs it and needs it to work for their own purposes. It's in the dogfooding that C#, for instance, gets so much attention (it is at the core - no pun intended - of .Net - OK, some pun intended). It's why C++, Fortran(!), and Cobol(!!), still get some love. Rust from Mozilla, Go from Google, and (everybody's favorite) Python from the Python Software Foundation (by way of Centrum Wiskunde & Informatica) - what they all have in common is the "dogfooding". That's the central factor for how resources are made available for language continuity and evolution.

Visual Basic never had that "dogfooding" feature to it. VB "Classic" was used as a prototyping device for Windows 95/98 GUI development, but nothing else really. The only thing in the Microsoft portfolio that uses VB.NET is the Roslyn-based VB.NET compiler - beyond that, nothing. Visual Basic was meant for Microsoft customers, particularly those who were buying it, especially for those who built their own in-house solutions on Microsoft OS's and DB's and other productivity offerings for the enterprise. To be fair, there was a burst of activity from 2010-2016 which brought so many fine enhancements and refinements to VB.NET. But then there was the sudden stop in 2017.

Along with the "dogfooding", there is also whatever steps are taken to promote a language's ubiquity. Typically, the language is offered for either really cheap or free (as in free beer). Happily, this angle is already covered - organizations with no more than several developers, and single developers, hobbyists, and students, can get Visual Studio Community for free. That's very nice. Doing VB.NET on Visual Studio Code is also possible, although as of today not pleasant - but it can be used for free by anybody of any size.

One final thing that means something, and that is governance - often by way of some kind of steering committee. Put another way, this is about giving voice to the users of a language. One way this is done is by way of a Standards Committee; e.g. the ECMA Standardization Process for C#. Historically, this issue of "users' voice" has been spotty for VB. It sort of improved when CodePlex was still a thing, and then sadly trailed off soon after the transition to GitHub.

So, of these ingredients - dogfooding, ubiquity, and governance - it's the dogfooding that needs the focus. A consortium of users from the business community, willing to meaningfully contribute resources, is the surest way to get VB.NET back in the game big time. Various sources (e.g. TIOBE, PYPL, RedMonk) indicate there's plenty of VB stuff still going on, so it's not too late to reinvigorate!

WolvenRA commented 4 years ago

@rskar-git Thanx. That was well said and good information. My first choice would be for MS to continue keeping VB equal to C# and accepting input and enhancements from the community. If that's not going to happen then we're going to have to do something along the lines you laid out.

You said, "To be fair, there was a burst of activity from 2010-2016 which brought so many fine enhancements and refinements to VB.NET. But then there was the sudden stop in 2017." What exactly happened in 2017 that caused the sudden stop?

paul1956 commented 4 years ago

In the short term, core support for VB needs to get finished it is happening though slower then I would like, second VB PR's for new features need to be treated with respect. If we can get those two things to happen VB can move forward. Otherwise it has no future here.I don't know enough about Open Source to know who to complain to when PR requests are just closed without discussion, that doesn't seem very "Open".

tverweij commented 4 years ago

I don't know enough about Open Source

Open Source only means that you can see the source. Nothing more, nothing less.

paul1956 commented 4 years ago

@tverweij so no obligation to work with community

tverweij commented 4 years ago

@paul1956 No.

I am not a big fan of "Open Source" or "Free software".

Open source means only that you can see the source, everything else is defined in the license (different for every project). For this project (.Net), it really means that you can see the source; the language teams decide what is allowed to build - the community may build then, and the developers at Microsoft decide what is good enough (and according to @AdamSpeight2008 it is never good enough).

If I look at other open source / free software projects like Lazarus and ReactOS, I see at Lazarus that a small group has taken over the complete project, do what they like (and not what is asked for) and they keep new contributers out because they are not good enough. With reactOS the same, with the result that it is still - after 25 years - not functional complete or stable; still alpha. And they still won't accept any (corperate) help or payment for development of specific parts of the OS, because that would make them dependent.

To be honest, I never saw an open source / free software succeed - it always stay alpha / beta or becomes abandonware.

But I can say the same about products from very big companies. They also do not finish products (UWP, Windows phone, Silverlight, Lightswitch, …) or abandom them (J++, VB classic , VB.Net?, …) and do not listen to communities; everything is about gain - not about the customers.

That is why I am investing in a propriety solution from a small professional group, that love their jobs, do really listen to their community and solve bugs (in most cases) within a day or week.

rskar-git commented 4 years ago

@WolvenRA

What exactly happened in 2017 that caused the sudden stop?

My guess is that the enterprise software market simply wants to capitalize on mobile app technologies, which for decades have favored - for reasons of pricing, licensing, and flexibility - LAMP ( https://en.wikipedia.org/wiki/LAMP_(software_bundle)/ ) and MEAN ( https://en.wikipedia.org/wiki/MEAN_(software_bundle)/ ). It would seem that by 2016, Microsoft determined that their traditional markets have stalled or receded, and that their vision of "Windows eveywhere" (e.g. https://www.zdnet.com/article/new-microsoft-windows-everywhere-ad-crosses-product-boundaries/) was losing out to Linux-based alternatives (which includes Google Android and Chrome OS).

Mobile app technologies - that awesome blend of websites, apps on tablets and smartphones, and servers - are a.k.a. the "Cloud". Microsoft long understood the trend, and launched Azure in the fall of 2008. It was likely hoped that there would be plenty of Windows Servers running .NET on virtual machines there, but even on Azure it was Linux-based solutions that soon dominated (https://www.zdnet.com/article/microsoft-developer-reveals-linux-is-now-more-used-on-azure-than-windows-server/). .NET could have run on Linux via Mono (https://www.mono-project.com/, https://en.wikipedia.org/wiki/Mono_(software)), but its adoption rate was frustrated over intellectual property concerns (https://en.wikipedia.org/wiki/Software_patents_and_free_software/).

Microsoft had long saw that their future successes were so much more in services. (Not exactly surprising, since so many other tech giants had come to the same conclusion for themselves.) To better leverage the Software-As-A-Service angle, .NET had to be accepted by the market as a true cross-platform alternative without any hint of IP surprises. Hence, .NET Core became a priority; anything not part of that focus is fair-game for triage.

I'm with @paul1956, in the short term, core support for VB needs to get finished. Microsoft still has enterprise customers that still have VB.NET code to maintain and expand, so .NET 5 must be good to VB.NET to stay in their good graces. After that, we'll just need to see...

pricerc commented 4 years ago

What exactly happened in 2017 that caused the sudden stop?

I have a couple of hypotheses:

1) collected data metrics. If, like me, you're in the habit of unchecking the box that says "Send usage information to Microsoft" (for whatever reason), then Microsoft doesn't know you're using the software.

2) questions being asked on StackOverflow.

You presumably know about "Lies, Damned Lies and Statistics".

I reckon some short-sighted people at Microsoft have equated the lack of "I'm using VB" from 1) and 2) as meaning there are few people using VB. This is a stupid conclusion to take.

regarding 1), I suspect most corporates are in the habit of avoiding sending unnecessary data to suppliers.

There are a few reasons why there could be few questions about VB on StackOverflow that have nothing to do with the languages popularity (or lack thereof). E.g. 1) VB is easier to use and understand, so people don't need to ask so many questions. 2) Because VB programmers don't need help with the language, when they do have questions, they are more likely to be .NET questions that are language-agnostic. 3) VB programmers don't want to be panned for being uncool, so ask their questions in C# instead of VB. 4) VB programmers are capable of adapting code from other languages, so they search for answers to problems in no specific language, and find solutions more often and so don't need to ask VB-specific questions.

I think this is one of the areas where Microsoft are losing their way. Along with the whole "Taking the Windows out of Windows" and "Taking the Visual out of Visual Studio". A lot of the new tooling out of Microsoft is now text and command-line based instead of GUI-based, which was Windows' (and Visual Studio's) whole point!

pricerc commented 4 years ago

One final thing that means something, and that is governance - often by way of some kind of steering committee. Put another way, this is about giving voice to the users of a language. One way this is done is by way of a Standards Committee; e.g. the ECMA Standardization Process for C#. Historically, this issue of "users' voice" has been spotty for VB. It sort of improved when CodePlex was still a thing, and then sadly trailed off soon after the transition to GitHub.

The weird thing is, if Microsoft don't want to develop VB further, then why not just donate it to the community like it did with C#? Let it become its own ECMA standard.

VBAndCs commented 4 years ago

For 15 years, MS broke the promise of making .NET work on any device and any OS. It did that on purpose thinking this gives Windows an advantage of other operating systems, and prevents .NET programmers from using it on other operating systems! This eventually turned out to be a catastrophic strategy, so, MS started too late to catch on. The sudden burst on new technologies in .NET make it difficult to duplicate things in C# and VB.NET together. They say it clearly: We want to attract C++ and Java developers to C#, so, we have no time to take VB.NET outside Windows! So, I keep thinking: Is there a way to write the same tools in Roslyn and VS.NET for Both VB.NET and C# just once? Is there a way to add the same feature to both languages with different syntaxes without any need to make changes to the code editor, debugger, etc in VS.NET? I spoke before about my desire to build VB# on top of C#. A new VB language that is translated to C#, So it can deliver a C# project to Roslyn and VS and get they response (errors, exceptions, hints .... etc) and translates them to the VB# editor. Something like an emulator that doesn't do anything except to produce a C# code and let C# carry on all the heavy lifting. This way, MS can focus on C# only, and we can translate any new C# feature to a VB# syntax , to get it up and running immediately! I also asked many times to allow programmers to defined and code templates that can be distributed with the project, so we an ad new blocks in the syntax as we desire. I also asked for generalized interpolated scripts to allow using any language code or script in strings in VB.NET and C#. If this happened, we can use C# inside VB code to make use of new C# features. So, in general, I agree with MS not to reinvent the wheel. But they need to think out of the box, to gave VB syntax a new life on top of C#.

WolvenRA commented 4 years ago

If I understand correctly, VB is not simply C# with different syntax. HOW the two languages accomplish something is not identical. Which is good! There is far more than simple syntax differences. Anthony explains many of those differences here: https://anthonydgreen.net/2019/02/12/exhausting-list-of-differences-between-vb-net-c/ Along with some explanations of why they were done differently. To be able to keep VB VB, we don't want just a "translator" that essentially lets you write C# code with a VB like syntax.

VBAndCs commented 4 years ago

I had read Anthony's artical and I write VB code for 23 years now. I really mean to change Vb Behavior in VB# to keep one compiler with two different syntax. Things like implicit cast can still done in the translation phase. Other odd VB behaviours that C-like programmers can't comprehend can be left out. If this is the way to keep vb a live, so be it. Old code bases can stand still with Vb.net as is. They need to evolve to go to. Net core. Besides, they can include vb.net projects with vb# project in the same solilution as they do today with c# in ASP.net core and xamarin. Using Vb# instead of C# will be a real gain. Anyway, I don't think there is anywone of the team here to listen any of this.

tverweij commented 4 years ago

I had read Anthony's artical and I write VB code for 23 years now. I really mean to change Vb Behavior in VB# to keep one compiler with two different syntax. Things like implicit cast can still done in the translation phase. Other odd VB behaviours that C-like programmers can't comprehend can be left out.

If you do that, you just killed VB

VBAndCs commented 4 years ago

If you do that, you just killed VB

This is what VB6 programmers still saying about VB.NET. By the way, I proposed to add a VB6.NET to VS.NET, but the team rejected it. I see no harm to have more than one VB dialect in VS.NET, so everyone can talk vb he prefers .

paul1956 commented 4 years ago

@VBAndCs split languages benefits no one, the tooling, the IDE, the refactoring's all would require duplicate efforts. VB.Net still does not have all the features that people wanted/used in VB6, if people have spare cycles it might be better adding some of those to VB.Net especially things like LinkPoke that could be added to WinForms and not touch the language and benefit all languages.

tverweij commented 4 years ago

If you do that, you just killed VB

This is what VB6 programmers still saying about VB.NET.

And they are right. This change made sure that everyone had to rewrite everything, because VB.Net was a new language, while the old one was not supported anymore.

But what I meant was that, if VB is nothing more than C# in an other syntax, I see no reason for anyone to use it.

tverweij commented 4 years ago

VB.Net still does not have all the features that people wanted/used in VB6

Isn't that an eye opener?

if people have spare cycles it might be better adding some of those to VB.Net

If only they would let us, this would be an option - but they won't let us.

06needhamt commented 4 years ago

@tverweij If they let us do It they wouldn't have to do 90% of the work anyway all they would have to do is review and merge our contributions. If they keep up with what they are doing they may as well declare VB.NET as dead as nothing would ever get done.

salelele commented 4 years ago

Many of us have invested heavily in VB/VB.NET because Microsoft encouraged us to do so and now we are facing the Visual Foxpro scenario. If Microsoft is not interested in advancing VB then they should let the community do so.

I would be interested in a new third party product that can compile VB.NET Code. It does not have to be called VB! It could be called something else. The guys who wrote the original Mono VB Compiler showed that it can be done.

VB does not need to be C#! But it does need to provide the tools we need for our work: web development with ASP.Net, Mobile development support for Android and iOS, Desktop application support at a minimum.

rskar-git commented 4 years ago

@salelele

The guys who wrote the original Mono VB Compiler showed that it can be done.

Be careful about what you wish for: Another feature of a language that is highly desirable is that there is a meaningful canonical/standard form of it that other vendors/developers align to for cross-platform and backward compatiblility reasons, preferably under one particular name. Bifurcations/forks that lack commonality in form and name will face many hugh challenges towards market acceptance. In addition to the time/money/staffing/skills required, there are also the factors of dumb luck and patience. If history is any guide, whomever embarks on this path is someone who has an immediate need and is therefore willing to put in the big commitment and take on the expense; and after that, it's a matter of whether whatever they come up with is somehow discovered and found compelling by others. See my post way above about "dogfooding".

On the other hand, if you really are actively looking for alternatives, @tverweij seems to have started one, and there are BASIC based commercial languages on the market today such as Xojo. However, I still think that a business-owner led consortium is the smartest way to go (initially focusing on what is immediately possible via the .NET Foundation). That would parallel how C became a standard and available from various sources despite it being a proprietary product from Bell Telephone Laboratories.

Mono itself has been part of the .NET Foundation since 2016, and they have been incorporating Roslyn (compiler system for C# and VB) since about 2014. Per https://www.mono-project.com/docs/about-mono/plans/: VisualBasic.NET support - Compiler no longer actively maintainted, we will adopt Roslyn's opensource compiler instead. But will keep developing the supporting runtime. Per https://stackoverflow.com/questions/29552190/has-the-roslyn-compiler-been-integrated-into-the-mono-project: Yes Roslyn has been integrated.

Per https://tirania.org/blog/archive/2014/Apr-09.html: Our goal is to keep track of Roslyn as it is being developed, and when it is officially released, to bundle Roslyn's compilers with Mono. ... Our goal is to contribute fixes to the Roslyn team to make sure that Roslyn works great on Unix systems, and hopefully to provide bug reports and bug fixes as time goes by.

Other links that are worth a look: https://stackoverflow.com/questions/37738106/net-core-vs-mono, https://docs.microsoft.com/en-us/dotnet/core/about, https://www.theregister.co.uk/2019/05/16/will_net_5_really_unify_microsoft_development_stack/.

tverweij commented 4 years ago

web development with ASP.Net, Mobile development support for Android and iOS, Desktop application support at a minimum.

@salelele see thread #491

VBAndCs commented 4 years ago

please take a look at #498 to gather all the efforts.

cristianlt23 commented 4 years ago

Um consórcio de usuários da comunidade empresarial, disposto a contribuir significativamente com recursos, é a maneira mais segura de colocar o VB.NET de volta no jogo em grande escala. Várias fontes (por exemplo, TIOBE, PYPL, RedMonk) indicam que ainda há muitas coisas de VB acontecendo, por isso não é tarde demais para revigorar!

@rskar-git

there is no better explanation! you were perfect! The VB.net world exists strongly in companies!

Congratulations for the comment, this is the niche of Vb.net and is what needs to be strongly publicized.

cristianlt23 commented 4 years ago

@pricerc

VB programmers don't want to be panned for being uncool, so ask their questions in C# instead of VB.

The community needs to help the VB.net Programmer to be proud of his syntax, to really wear the shirt and to say that he is a VB.net programmer.

This really happens, if you ask many in which dialect you write your programs, many say they are ".Net" and others lie and say "C #" just to join a nice group of people, while in fact you should hit your chest and say " I am VB.NET from the beginning to the end of my projects ".

VB programmers are capable of adapting code from other languages, so they search for answers to problems in no specific language, and find solutions more often and so don't need to ask VB-specific questions.

The strongest truth of the query reality of the VB.net programmer, Congratulations on the comment on the fly!

longwolf commented 3 years ago

On a different note: if Microsoft really love C# more than VB.NET, why didn't they put just a little bit more effort in e. g. code beautification? In VB.NET, the code is rearranged really fast, painless, and without hassle. In C#, I have to wait a few tenths of a second (thanks to really fast processors; it was/is several seconds on slower machines where there is still no human-noticeable delay with VB).