hartmair
commented
5 years ago Open hartmair opened 5 years ago
hartmair
commented
5 years ago 
pricerc
commented
5 years ago given the reference to #439, there's data-type characters for starters, although some would like to see that expanded, which necessarily doesn't support the proposition that they are 'legacy' constructs.
I would suggest some other features that jump to mind, that would be just assumed in 'Non-legacy' mode: Option Strict On Option Infer On Option Explicit On Option Compare Binary
I have some sympathy with the idea, because there is some truth to the idea that maintaining backward compatibility means that the whole job of maintaining the compiler is much more complex. I'm not sure that data-type characters is the best example of that (since I imagine that they have very little impact on the complexity of the compiler).
That said, having an option to turn 'legacy' on-and-off would just make maintaining the compiler even harder, because the compiler would still have to know how to do both.
I think if you really want to go down that path, and the goal is to simplify the current language while making new features easier to implement, then a fork into a new flavour of VB may be an option, as has been suggested elsewhere on this forum. I think someone suggested a VB.Core, and I think that has some merit - if someone has the time and energy*. I could see it being used as a platform for implementing new features without the limitations of maintaining backward compatibility, with the possibility of porting said features back into the main VB stack once they've stabilised (because first generation implementations of concepts are often flawed). The first 'refactoring' step in the fork would be removing all the branches for 'legacy' constructs.
* I have neither, as I am self-employed and writing open-source compilers doesn't make money :(
As an alternative that could do even more, what about an Option Compiler <CompilerOptions> that goes right in the source code (instead of just in the vbproj file), that would allow the developer to specify the compiler flavour/generation they're coding for. A 'preprocessor' step could find it, and then know that it needs to use a specific compiler (which could be in a separate assembly), that might have different rules and optimisations. Options would include options that can currently be coded into the .vbproj file (like compiler version), but could also include things like the intended target platform (say, Desktop, Mobile, IoT, Core, Standard, Full), or the desired compiler compatibility level - Current, Stable, Legacy, BleedingEdge, 14.1, 15.0) etc. They would allow for intelligent compiling of individual code files (e.g. for VB.Net scripting) without needing a .vbproj file or command-line switches for those settings. Initially, there may be multiple options that mean the same thing, but if the basic Option is there, it would allow for divergence if appropriate, and for easy addition of new options later on.
pricerc
commented
5 years ago I would suggest some other features that jump to mind, that would be just assumed in 'Non-legacy' mode: Option Strict On Option Infer On Option Explicit On Option Compare Binary
i.e. pretty much anything that's been added as an option because the 'New' option is considered an improvement, but the 'Old' option is necessary for backward compatibility.
hartmair
commented
5 years ago @zspitz @pricerc Thanks four your feedback/ideas - I updated the description.
ericmutta
commented
5 years ago @pricerc I think someone suggested a VB.Core, ...
That was me! :smile:
The idea lines up with what @hartmair is aiming at in this proposal. Basically we need a fork of the VB compiler and for this discussion let's say the current compiler is called "fat" and the new compiler is called "lean".
The "fat" compiler will remain largely unchanged (as it has been anyway) and will not get new features going forward. It will support all the stuff (hence the word "fat") that probably makes life hard for @jmarolf and team when they have to consider how new features will interact with VB's vast surface area.
The "lean" compiler will first begin by removing support for everything that is no longer allowed when you compile with Option [Infer|Strict|Explicit] On. (I would keep Option Compare around because personally I write all my code with Option Compare Text in keeping with VB's case-insensitive nature).
Next we would also remove support for legacy error handling (i.e On Error Resume Next and friends) . We have Try...Catch for that which is far superior.
We would also remove support for any parts of the VB run-time that have counterparts in the BCL (e.g the file handling stuff). Since these are just functions, I imagine they could become a NuGet package that someone adds to their project (like with any other library) if the really need something in there.
Regardless of how this ends up being done or what the compilers are called, the goal is making the compiler leaner, faster, easier to maintain and most importantly easier to add new features to.
This would be the type of thing that would pay significant dividends if we take a 10-20 year view of the future of VB because one thing is for sure, if the current "snail's pace" of evolution remains a fact for another 3 years or so, a permanent loss of momentum could see the language dwindle into obscurity.
I remain optimistic however and believe amazing things are going to happen to this language (slow though they may be) :smile:
pricerc
commented
5 years ago @pricerc I think someone suggested a VB.Core, ...
That was me! 😄
I had meant to look harder for the suggestion, but figured someone would own up :)
I really think this has merit. There have been a bunch of really good suggestions for new features that have a common problem of being likely to break backward compatibility (often of "edge cases"), and so naturally end up in the "too hard" basket.
If it's practical to have two discrete compiler assemblies (say, vbc and vbcc), and be able to choose which one to use in project settings, then I could see it catching on.
Besides the stuff you've mentioned, what else would you want to see change?
Candidates I can think of (based on items I've seen in this forum):
ericmutta
commented
5 years ago @pricerc Besides the stuff you've mentioned, what else would you want to see change?
As you noted earlier, we've had a wide range of suggestions in this repo, but exactly ZERO among them have been implemented. In fact NOTHING NEW has been implemented for a long time now and the reason probably boils down to the difficulty of adding features to the VB language when compared to C#/F#.
As a matter of fact, if the ideas in this issue will ever see the light of day, I think we need to reduce the ask to exactly one line to begin with: remove support for turning off Option Infer, Strict and Explicit.
Just that change alone would reduce the complexity of adding new features by a factor of EIGHT. The three on/off options act like a 3-bit number with 8 unique combinations, which means when adding a new feature to VB you have to consider its semantics under the 8 different combinations of Option Infer/Strict/Explicit. This burden simply does not exist in other languages and removing it could dramatically speed up VB's evolution even if all the other legacy stuff is left as is.
CC: @KathleenDollard would it be possible to table this at the next LDM and give us some feedback?
zspitz
commented
5 years ago the reason probably boils down to the difficulty of adding features to the VB language when compared to C#/F#
I would suggest that aside from the greater difficulty in evolving VB.NET over C# and F#, there is a smaller community around VB.NET and lower community participation (filing issues, responding to proposals, suggesting PRs, testing against private projects). As an off-the-cuff measurement, the C# language design repo has ATM 1531 open issues/proposals since January 2017; while this repo has an order of magnitude less (315) in the same time frame. Lesser community involvement means slower development.
What can we do about this? I would suggest that if you feel passionately about having a given feature in VB.NET, you should do the following:
Note that the goal here is NOT to get a fully functional feature into VB.next which will come out in another month or two. The goal is to have a spec and a working implementation as the starting point for further discussion, rather than just some vague words in the air which the LDT has to now develop an initial spec and implementation before even beginning the discussion.
(I would go so far as to suggest that any proposal on this repo which can be spec'ced, should be spec'ced (using the grammar available here as a starting point).)
ericmutta
commented
5 years ago @zspitz Fork the compiler and attempt to implement the feature.
This is very much on point! I think it's time to just dive in and start figuring out what this Rosyln thing does. Towards that end, I have started reading the overview in order to get a high-level view and it's pretty interesting reading so far!
My personal goal for the rest of the year, is to get comfortable enough with Rosyln that I can make trivial changes (like adding support for trailing commas in array literals). Once Rosyln no longer feels like a strange beast, it should be easier to move on to real-world changes :+1:
UPDATE: so I just spent the past two hours trying to setup the Rosyln code on my machine to the point where it can build successfully. It is not an easy thing to do! With a project of this size, everything is big: the dependencies are numerous, the downloads are big, the build times are long, etc. You have to be really motivated and if you have other responsibilities, it's easy to give up midway. On a positive note however, the Rosyln source browser is pretty cool and the code base itself is generously documented so you can at least begin poking around from the comfort of your browser :+1:
hartmair
commented
5 years ago @ericmutta I removed Option Text from the list and added On Error statement
hartmair
commented
5 years ago @ericmutta
I think we need to reduce the ask to exactly one line to begin with: remove support for turning off Option Infer, Strict and Explicit.
I disagree - after just eliminating Option Infer, Strict, and Explicit Off via Option Legay On we would need to introduce another Option Legacy2 On in order to get rid of all the other stuff
ericmutta
commented
5 years ago @hartmair I disagree - after just eliminating Option Infer, Strict, and Explicit Off via Option Legay On we would need to introduce another Option Legacy2 On in order to get rid of all the other stuff
What I mean is we shouldn't have Option anything...the lean compiler would work as if all the options were on and there would be no way to turn them off so it doesn't have to worry about the 8 different on/off combinations that it has to deal with now...it's the presence of these options that I believe make it a lot harder to evolve VB. I will also admit that this is pure speculation on my part since I have no knowledge of the compiler's internals and hope someone like @jmarolf can shed some light on this line of thought.
hartmair
commented
5 years ago @zspitz
What can we do about this?
I think this is what #445 aims for
KathleenDollard
commented
5 years ago We will not make changes to VB that are not backwards compatible. There are some caveats about fixing bugs and such. But removing features as basic as the Options would break a lot of people's code.
Roslyn is hard. Almost everyone who contributes to it is either on the team or has been on the team. It's hard because it is an incremental compiler to support Visual Studio. It's 4 million lines of code. I hate to be a bummer here, but I have never seen anyone not underestimate the complexity of Roslyn (including myself).
And please talk to us before investing a lot of time in work you want us to merge. We will continue to be very careful with the changes we make to all of the repos that we shepherd.
Padanian
commented
5 years ago Every single one of Kathleen's messages on this board has been a complete and utter disappointment. Maybe it's time to look around for some other language, one with cross-platform capability that works, and some other IDE. Today, in 1975, Paul Allen and Bill Gates created Altair BASIC. Remember your legacy.
----- Messaggio Originale ----- Da: "dotnet/vblang" A:"dotnet/vblang" Cc:"Subscribed" Inviato:Wed, 19 Jun 2019 00:49:47 +0000 (UTC) Oggetto:Re: [dotnet/vblang] [Proposal] Option Legacy On|Off (#448)
We will not make changes to VB that was not backwards compatible.There are some caveats about fixing bugs and such. But removing features as basic as the Options would break a lot of people's code.
Roslyn is hard. Almost everyone who contributes to it is either onthe team or has been on the team. It's hard because it is an incremental compiler to support Visual Studio. It's 4 million lines of code. I hate to be a bummer here, but I have never seen anyone not underestimate the complexity of Roslyn (including myself).
And please talk to us before investing a lot of time in work you wantus to merge. We will continue to be very careful with the changes we make to all of the repos that we shepherd.
—You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2]. [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/dotnet/vblang/issues/448?email_source=notificationsu0026email_token=AB3I2BDCNPUJTLPZJZU7A4LP3F7CJA5CNFSM4HXKWQJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYALO3A#issuecomment-503363436", "url": "https://github.com/dotnet/vblang/issues/448?email_source=notificationsu0026email_token=AB3I2BDCNPUJTLPZJZU7A4LP3F7CJA5CNFSM4HXKWQJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYALO3A#issuecomment-503363436", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]
[1] https://github.com/dotnet/vblang/issues/448?email_source=notifications&email_token=AB3I2BDCNPUJTLPZJZU7A4LP3F7CJA5CNFSM4HXKWQJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYALO3A#issuecomment-503363436 [2] https://github.com/notifications/unsubscribe-auth/AB3I2BAY3HXHBBV5GSNZYOLP3F7CJANCNFSM4HXKWQJA
ericmutta
commented
5 years ago @KathleenDollard: We will not make changes to VB that are not backwards compatible.
Thanks for providing feedback on this discussion. I understand the need for preserving backward compatibility (even for features that have been "legacy" for 20+ years) however I believe evolution is just as important.
This "evolution vs compatibility" problem seems to have found a solution when it comes to the .NET Framework where the path taken was to fork the framework so that the .NET Framework remains the backward compatible implementation while .NET Core is where all future innovation will happen.
Can't we consider something similar for VB where the current compiler remains the backward compatible version and a "VB .NET Core" fork is created where the focus will be on innovation with backward compatibility preserved only where it supports innovation (e.g Option Strict On is good and the recommended way to write production code, so any code that uses it now would continue to work in VB.NET Core but code relying on it being off would have to use the current compiler)...?
And if the answer to the above question is another "NO" then I have one final question: as the leader of this community, does it not concern you that VB's lack of evolution relative to its peers will eventually kill it or wipe out its already small community?
franzalex
commented
5 years ago And if the answer to the above question is another "NO" then I have one final question: as the leader of this community, does it not concern you that VB's lack of evolution relative to its peers will eventually kill it or wipe out its already small community?
@ericmutta [^]
This is the impression I've always had with regards to the development of VB.NET. It is weighed down by the need for backwards compatibility with features introduced to 'aid' the transition from VB6. The last time I remember seeing any new feature introduced into the language that wasn't due to wide-reaching changes to .NET was in 2015 when we had the introduction of comments after implicit line continuation.
In the years I've been following this repo, I've seen so many proposals get turned down from the Github Issues discussion stage all the way up to LDM. Now, with a new change in direction from .NET Fx to .NET Core, we have the opportunity to remove the extra baggage and fork a leaner version of the language with a greater potential for rapid evolution and unfortunately the decision to remain with the old, stagnating system still remains.
I'll join the masses in flogging the dead horse by saying this: decisions that lead to lack of evolution of the language WILL eventually kill it off.
hartmair
commented
5 years ago @KathleenDollard
We will not make changes to VB that are not backwards compatible
Let me clarify: Option Legacy On means no changes (and even more no breaking changes). Only when choosing Option Legacy Off, this will involve minor breaking changes.
I think what you want is Option Legacy On as default, right?
But removing features as basic as the Options would break a lot of people's code.
This issue is about adding a new Option, not removing the others.
KathleenDollard
commented
5 years ago @hartmair Great! I was confused by the part of this thread that suggested this would make life easier for the compiler.
It is true that change has been slow to the Visual Basic language, and because of the way we've communicated, the significant efforts that make developers life better in Visual Studio have not been as obvious. And we've put effort into getting Visual Basic onto .NET Core. With that effort, I have some upcoming articles lined up (if anyone is doing something cool in VB.NET they want to share, either for a magazine writing to length with editing, or on the blog, let's discuss) so VB will not be so terribly quiet.
This slow pace of language evolution (and other quietness) has not had an impact on Visual Basic usage. The percentage of VB.NET development remains approximately where it was two years ago when we did the language strategy blog post. That is not a reason not to look at targeted improvements to the language. It is simply pointing out that there is no current evidence that VB.NET will die if the language doesn't evolve.
I think ecosystem things that are much easier for the community to control are more interesting. We aren't sure where "My" should be in .NET Core because it has some pretty old thinking. Should that become a common namespace that you select a version(s) you want from NuGet? Can we do something in the community on the Blazor or TryDotNet fronts? The Entity Framework templates have been languishing because the team that did "bring your own language" hasn't gotten much community support for that. These are all places where the community can have significant impact on the lives of developers (in addition to feedback on language evolution, and potentially contributions - it's just that Roslyn is really hard).
Padanian
commented
5 years ago If the Entity Framework templates are being ignored, probably nobody is interested. Or at least it is not as much interested as you at MS are. Thanks for confirming that vb.net development is stuck where it was two years ago, and thanks for confirming the evidence that it is actually already dead.
KathleenDollard
commented
5 years ago @Padanian I'm sorry you took that from my message. If you'd like to clarify why you saw that in my message, I'd be happy to clarify.
ericmutta
commented
5 years ago @KathleenDollard: The percentage of VB.NET development remains approximately where it was two years ago...
So where is the outrage? Is that something that you really find acceptable? All of the angst you see around this repo is based on this state of affairs.
@KathleenDollard: we aren't sure where "My" should be in .NET Core because it has some pretty old thinking. Should that become a common namespace that you select a version(s) you want from NuGet?
"My" and all other parts of the VB run-time that are not VB-specific or have alternatives in the BCL should just be NuGet packages that anyone can use. Over the years it has existed, I only use My to get my application's current directory. Stuff like that shouldn't be baked into the language and should probably be pushed into the BCL for common distribution.
@KathleenDollard: ...it's just that Roslyn is really hard.
I think by Rosyln here you mean specifically the VB compiler because Roslyn's hardness has not prevented C#/F# from evolving in the past two years.
So again I ask: where is the outrage?
I am sorry to say this Kathleen but I think VB just isn't a priority for you because if you have any love for it, I am just not seeing it!
We need you to go thermonuclear and demand on our behalf, that at least once or twice a year, a release of Visual Studio ships with improvements to VB that make sense for VB. Visual Studio itself is probably ten times "harder" than Rosyln and the damn thing ships several times a year. VB needs to do better! A lot better.
zspitz
commented
5 years ago @ericmutta
I think by Rosyln here you mean specifically the VB compiler because Roslyn's hardness has not prevented C#/F# from evolving in the past two years.
I would suggest that Roslyn is hard, but C# has both 1) a larger user community in general, and 2) a larger percentage of that community is active in opensource; this offsets the difficulty of Roslyn. (NB. F# doesn't use Roslyn, and AFAICT is mostly community-driven).
I think we have to understand that evolving the VB.NET language in itself (as opposed to developing the ecosystem) has less business value to Microsoft. Unless it's low-hanging fruit involving really minor changes, or significant and severe errors, there is less justification for Microsoft to expend the required resources.
However, I say again, new features require far more than just implementation, both before and after; we -- the members of the VB.NET community passionately involved in opensource -- can do a lot of this work:
I believe that even if we cannot evolve the language directly -- that's up to the language design team -- we (the community) can and should shoulder part of the burden and make it easier for the team to do so.
(ping @KathleenDollard )
AdamSpeight2008
commented
5 years ago There are three proposals of mine, that do have prototype implementations. Haven't even been discussed (as for i can tell) in 2+ years. Feels that they are punishing the community for my passionate attitude to towards the language.
AdamSpeight2008
commented
5 years ago Even the ones accepted don't seem to be progressing from "the team" side. Implicit Default Optional Parameters would be a great feature for the language and wouldn't take long to implement. Since most of the work has already been done. From my understanding could be added in point release.
KathleenDollard
commented
5 years ago To cover a few points with my opinions. This isn't an official Microsoft statement:
Do I love VB enough? It seems an odd conversation. Visual Basic, and Basic before it is the most amazing language we've ever seen, by far. Hand someone some code written in almost any language and ask them to read it aloud. Write the words down and they'll be pretty much ready to compile in Visual Basic (if .NET) or Basic.
Visual Basic has also had decades of evolution. It's a grown up language not still trying to "find itself" which C# seems to me. VB came to .NET as a pretty grown up language due to the VB6 evolution. The fact you can read code across any generation of Visual Basic.NET and Google/Bing for a rare thing that is unfamiliar is absolutely amazing and a huge benefit. Stability is a feature. If you open a legacy C# project, you have no idea what style of code you'll find. If you open a legacy VB project, you know what style of code you will find.
I also worry about the ecosystem, and you all have a big part in how that works out.
That's not to say I'm not thinking about features. And it will be a while until we start work on VB Next so it's not a conversation that will be very active for a while. We're still months away from getting Visual Basic .NET 16.0 out the door.
The biggest thing you could do for Visual Basic.NET right now is to download .NET Core Preview 6 and give feedback on how well it works for you. Testing is not the same as having it in the hands of real users. That's the foundation for the language features we'll do in the future.
(I also love and talk about C#. I like teenagers too.)
VBAndCs
commented
5 years ago You can add all vb6 methods that have duplicates in the framework like string and date functions. But I don't think removing goto is wise, because it splves some issues like exiting nested loops in some conditions. I also called for VB.Core in #404 but as an upgrade to vb.net to the new. Net core.
KathleenDollard
commented
5 years ago @ericmutta I got distracted by other points. On this:
"My" and all other parts of the VB run-time that are not VB-specific or have alternatives in the BCL should just be NuGet packages that anyone can use. Over the years it has existed, I only use My to get my application's current directory. Stuff like that shouldn't be baked into the language and should probably be pushed into the BCL for common distribution.
This aligns with what we're currently thinking.
paul1956
commented
5 years ago The issue I have is without them, at least for me, none of my application port to core. Using NuGet is great but I would like some of my applications to run on non-Windows platforms which is the real promise of Core and pushing into BCL may not give VB behaviors. The VB runtime is more than just a very thin layer, there are places where VB does something very different then what for example System.IO does for a similarly named function. VB has a lot of UI options around all the file IO for example.
pricerc
commented
5 years ago there are places where VB does something very different then what for example System.IO does for a similarly named function. VB has a lot of UI options around all the file IO for example.
But you have to wonder why many of those things only exist in VB. Surely simplified access to IO is something that would be attractive to developers in any language?
I can't help but suspect that a lot of (e.g.) C# developers would like to use functionality in the VisualBasic namespace (because they're convenient), but cringe at the thought of contaminating their code with VB 'germs'. I've seen a few comments to that effect in StackFlow.
If we could get those things out of 'VB' and into the 'the wild', it could be helpful to a wider community than just VB.
Some examples of related articles on StackOverflow: https://stackoverflow.com/questions/226517/is-the-microsoft-visualbasic-namespace-true-net-code (10 years old, but I think exposes some "interesting" thinking around VB vs C#) https://stackoverflow.com/questions/6115194/what-is-equivalent-to-microsoft-visualbasic-collection-in-c https://stackoverflow.com/questions/15591130/microsoft-visualbasic-fileio-does-not-exist-trying-to-use-textfieldparser https://stackoverflow.com/questions/3721540/issue-with-microsoft-visualbasic-interaction-msgbox-method
paul1956
commented
5 years ago I think it would be great to make available to everyone, my point was the functionality is needed. Being able to copy a directory in 1 line is universally useful, making everyone write the function outside of a CS 101 class seems dumb. VB also handles the UI (Overwrite? for example) but this requires a UI that is platform independent to get any traction outside of Windows/VB.
KathleenDollard
commented
5 years ago @paul1956
The "My" namespace can have modern implementations community driven and available in NuGet that can focus to the things people actually need and provide cross platform answers as much as possible. This is more powerful and flexible than a direct port of Windows specific features.
As a side effect it would not require referencing the microsoft.visualbasic.dll so may enjoy wider success. The Gitter channel might be a great place to kick off an effort on "My" https://gitter.im/VB-NET
paul1956
commented
5 years ago @KathleenDollard unless I am mistaken every existing VB application has the following
are you proposing that the community needs to implement this and its designer?
hartmair
commented
5 years ago I'd like to point out that this discussion is going off on a tangent. There is already an issue for porting Microsoft.VisualBasic.dll to nuget #458
paul1956
commented
5 years ago I published a reasonable VB MsgBox to NuGet https://www.nuget.org/packages/VBMsgBox/1.0.1. Feedback welcome this is my first NuGet package.
Can we please get rid of all the "legacy" stuff. For example,
This is not what I consider VB.NET or beautiful readable code. This way, we could get new features faster to VB.NET since we don't have to consider VB6 syntax anymore.
Details
In case of
Option Legacy Off, a different compiler applies (vbc and vbcc), which does not support the following:Note that this list is somewhat subjective and thus may change. For now, it is just an incomplete start of what could be "legacy". Some candidates can be found in Statements and Keywords.