What should new VB features 'look' like, and how should proposals be presented?

[pricerc]

Over the months that I've been following things here, the many suggestions for new features have varied greatly in quality, both in the quality of proposal, and in the quality of presentation.

I don't typically have very strong feelings about things. I can be a bit of a troll, and I like playing "Devil's advocate" on just about any topic. So my points on this forum are usually about getting people to think about aspects of proposals that are not obvious at face value.

But I do have a strong opinion on one thing, and that is that Visual Basic should be its own thing, independent of other languages, and only adopt paradigms and "cool new things" that will enhance the language as a rapid application development tool (for business and casual users alike) that encourages code that remains easy to maintain years later by other people. I think that abandoning "Feature Parity" between C# and VB was a good thing, because both languages were being constrained by the requirement that they be "cross-translatable", which diluted their individual strengths.

The things that have been a recurring theme for me in triggering responses to proposals are:

1) proposals that don't look like "VB" to me.

2) proposals that don't adequately address how they enhance the language.

3) proposals that I can't follow because they have inadequate examples, or examples that don't compile (I understand that you can't compile a new feature, but many proposals are about new ways of doing old things, where the old things are pain points for the proposers, and having compilable examples helps make the point)

So I have two questions/requests for discussion.

1) What should Visual Basic "look" like? There's a bit of a document on the proposal process VB Language Proposals, but I haven't been able to find guidance on what the language's "style" and "look-and-feel" should be (or should not be). I think without this kind of guidance, you end up with bits of other languages being recommended for inclusion as VB elements in a non-VB way. For example, my pet peeve that I think was a mistake was the use of braces (curly/squiggly brackets) for variable initializers - With already had a perfectly acceptable End With, so

Dim a = New SomeClass() With { .Name = "Foo", .Value = "Bar" }

looks like VB and C# had a confused baby, when

Dim a = New SomeClass() With
    .Name = "Foo"
    .Value = "Bar"
End With

looks more like VB and, ignoring the End With (which the editor types for you), is less typing, and would have made converting from this easier:

Dim a = New SomeClass() 
With a
    .Name = "Foo"
    .Value = "Bar"
End With

2) Can we get guidance (perhaps in https://github.com/dotnet/vblang/tree/master/proposals) on what a good proposal should look like and what it should contain? Perhaps including some examples of good and bad proposals from this very forum (possibly redacted to protect the guilty). I frequent SQLServerCentral.com where they have some "forum etiquette" guidelines that advise on how to ask a question to get the best response Forum Etiquette; perhaps something equivalent for vblang/issues would be helpful?

Perhaps even a couple of templates, around different types of enhancement?

I'll kick off the discussion with an initial thought on what should be in a proposal. Based on my experience with "user stories" that one might use in agile development, I think a proposal should read a bit like a user story:

When I am implementing well-known pattern XXX, I find that I need to always add YYY, which is derived from XXX. This is tedious and error prone. If the compiler was able to implicitly add YYY, then my code would be more reliable, easier to read, and easier to maintain. Possible ways to do this include new attributes and/or syntactic sugar.

[ericmutta]

This is an important meta issue that is definitely worth discussing :+1:

When filing issues in the roslyn repo, you get a predefined template to follow and perhaps having something similar for this repo would help. The template could include questions like these:

1. What problem/issue/challenge is your proposal addressing? Show briefly, with real code, what you believe can be improved via the proposal you are submitting.

2. Why is the problem worth solving? Which class of developers or application types would benefit most from the solution?

3. What solution(s) are you proposing? Give at least one suggestion to kick off the discussion, and ideally include code that shows a clear improvement over the code you gave in question one.

I believe those should be enough (though suggestions/modifications are welcome). Some minor rules would be to (1) check spelling and grammar before submission and (2) keep things as brief as possible so busy people can read proposals in full before contributing their thoughts.

Finally, and I think we touched upon this in the past, we need a way to "expire" issues so they can be closed if they haven't gone anywhere after a specific period of time. This could be automated with the rule being that if an issue hasn't seen activity in 30 days, a bot could post a comment to notify that it will be closed in 7 days and participants in the issue can up/down vote the comment to tell the bot whether they agree or disagree. The ultimate purpose is to keep the repo "lean and mean", containing just the issues that will probably get implemented down the line :+1:

[KathleenDollard]

A few comments on proposals:

• Issues here are for discussion. This is rather successful if you compare the language design work with what goes on in other repos. You folks are awesome! Let's not put in structure at a level that changes this.
• Asking for correct grammar and spelling from a multi-lingual community is a significant ask, because people are kind enough to work in English here even if it isn't their first language. I hope people will do what they can, but I don't ever want a good idea critiqued for English usage.
• The length of a proposal reflects many things, including how complex or deep the proposal is. I'm fine with brief though.
• The questions you propose are good.

Microsoft repos don't generally expire issues, so I am not in favor of that. Some issues that don't get attention now may be considered in the future. The LDM has been labeling issues as time allows.

[tverweij]

I just read the release notes of Visual Studio 2019, to see what proposals for VB.Net made it in to it. And What do I see? The section "Programming Languages" contains: C#, C++, F#, JavaScript/TypeScript, Python No mention of VB.Net at all, nowhere in the release notes. As if it doesn't exist.

So, what is a proposal (in whatever form) worth if the language is not even mentioned anymore by Microsoft?

Edit: It is mentioned once, below IDE: Collaborate with others using Visual Studio Live Share, which is installed by default. Additional language support for C++, VB.NET, and Razor gives guests a solution view and sharing of source control diffs.

And that's all.

[paul1956]

@tverweij I raised this elsewhere, so sorry if it is a dup but VB is not even listed on the VS 2019 survey of what language are you using with VS. I missed the reference to Visual Studio Live Share.

2019.1 (starting with Preview2) will have a couple of new VB features, I hope there is also a comment in the readme file.

[KathleenDollard]

The Visual Studio 2019 release notes for C# are about features that are not available by default in Visual Studio 2019, but only after a separate installation changing two settings on separate nested dialogs. I won't comment on whether that was a good decision for C#.

Those C# features are in .NET Core 3.0 Preview 3. The Visual Basic feature we are working on for .NET Core 3.0 will appear in a later preview. Preview 4 or 5 will also contain @paul1956 change to allow line continuation in more places.

There wasn't a way to say "coming soon" in the release notes.

I am working on articles and documentation close to the release of .NET Core 3.0. If anyone is interested in helping, feel free to reach out.

[ocdtrekkie]

Kinda wish GitHub had a spicy emoji reaction I could attach to the last comment.

[pricerc]

An interesting discussion going on.

I've mixed feelings about VB's presence (or lack there of) on Visual Studio release notes. It seems to me that, strictly speaking, Visual Studio and the languages are now discrete products on slightly different release schedules, and that they should each be doing their own release notes. And if VB doesn't need new features from Visual Studio (because it's already so awesome and well-integrated), then there's no real need for anything in the release notes!

Having said that, I still haven't got an answer to one of my questions, about VB's 'style'. @KathleenDollard, is there any kind of document on what VB's "Look and Feel" should be? As in, what are the guiding principals behind the choices made in terms of structure, keywords, syntax and semantics?

Without a guideline, there is a risk of the unique flavour of VB being lost to dilution by constructs adopted from other languages, which I fear we'd all be poorer for.

As a specific example, there are two similar (but not identical) proposals relating to removing Dim for declaring variables. The merits or otherwise of those proposals is not important here, but what would be helpful is to have a clear understanding of why we have Dim today. So is there (for example) any documentation on the decision, when going from VB6 to VB.Net, on retaining Dim as the only way to declare variables? If such information was available, then it could be referenced in the discussions around proposals, and it might help people understand why VB is the way it is, and help us all make better VB-like proposals in the future.

[paul1956]

What I found most interest since using VS 2019 with VB is all the new features that I had to discover myself or that were only listed as C# features that work well (but not perfect) with VB. The new refactoring's, the formatting of lists... when I looked for them in Options the preferences only appear under C# but the features can be used by VB. I looked for the cleanup document and that I can't find but still searching. This seems like an easy oversite that could be fixed in 19.00001 since it "only" involves updating the readme. There also seems to be a major update to the Roslyn SDK that effects VB, programs that use it return different results, some of my failing tests pass and passing tests fail (I believe all for the correct reasons) but this also should have been documented somewhere. That said I really like VS2019 as a VB developer despite the rough edges.

[zspitz]

@pricerc

Having said that, I still haven't got an answer to one of my questions, about VB's 'style'. @KathleenDollard, is there any kind of document on what VB's "Look and Feel" should be? As in, what are the guiding principals behind the choices made in terms of structure, keywords, syntax and semantics?

Like this?

[pricerc]

@zspitz

Like this?

yes. Exactly like that.

I specifically think we need a (semi-)formal document from the LDM.

We do have the VB language spec, and while it covers the existing grammar, there is no history, nor 'goals' or 'whys' in there.

I presume there is some kind of documentation on how we got to where we are. At the very least the things you mentioned deserve a place readily accessible from this repo's README.md. Perhaps a short version of a 'style guide' in the README.md itself, with a link to a longer form, which could even be just an issue on its own, or live in its own folder, like the language spec.

[zspitz]

@pricerc There's also the points in the second list item here:

A good proposal should:

• Fit with the general theme and aesthetic of the language.
• Not introduce subtly alternate syntax for existing features.
• Add a lot of value for a clear set of users.
• Not add significantly to the complexity of the language, especially for new users.

which should also be incorporated.

[pricerc]

A few comments on proposals:

* Issues here are for discussion. This is rather successful if you compare the language design work with what goes on in other repos. You folks are awesome! Let's not put in structure at a level that changes this.

It doesn't have to be strictly structured, but for many suggestions, I spend a fair amount of time trying to puzzle over things like "What problem is this trying to solve?", and "I'd like to reproduce the scenario, but their code doesn't compile". So if we could encourage people to think about these things before posting, then it would help others to understand the proposals.

* Asking for correct grammar and spelling from a multi-lingual community is a significant ask, because people are kind enough to work in English here even if it isn't their first language. I hope people will do what they can, but I don't ever want a good idea critiqued for English usage.

I know I speak for many when I say that I'm grateful for all the non-English speakers making an effort to communicate with me. I know English is a bit of a challenge to master, even for many for whom it is a first language. So I'm not too fussed about (other people's) spelling and grammar (if I was, I'd have to stay off the InterWebs; even our newspapers have shocking grammar and spelling these days).

* The length of a proposal reflects many things, including how complex or deep the proposal is. I'm fine with brief though.

Brief is fine, as long as they have a reasonable "What" and "Why", and an example of "How" they think things should look.

[pricerc]

@pricerc There's also the points in the second list item here:

• Not introduce subtly alternate syntax for existing features.

covers quite a few proposals I've seen that have had me wondering: "Why?"

If these were centrally documented in some guidelines, then we could potentially refer authors back to said guidelines.

[AnthonyDGreen]

In short, that's part of the function of the language design team. To massage ideas into things which "look" right and fit into the language and reject things which don't. An idea ... isn't usually rejected PURELY because the hypothetical syntax chosen isn't quite right. It's often the case that the syntax is off AND the idea doesn't work regardless of syntax. Or even if the syntax is great but the idea itself doesn't work. See that all of the time.

In my time on the LDM (2010-2017) we always debated keywords and syntax, even when taking a feature over from another language or implementing it at the same time in both languages. So originally, C# was going to go with the "This is an \{interpolated} string" syntax and VB was, for the same feature (which I implemented, btw), introduced at the same time go with the syntax it has now $"Hello, {name}". The $ is actually an intentional hardcore reference to the $ meaning "string" in various Microsoft BASICs, including VB.NET. It just so happens that eventually C# came around to the VB syntax.

VB was originally considering GetName instead of NameOf, to be consistent with GetType but GetName seemed waaaaay more common and likely to either break code or be entirely useless and ultimately NameOf(Element) actually read better.

VB added iterators in 2012 and added a new keyword Iterator and used Yield instead of going the way C# went, no keyword and Yield Return. Incidentally VB also added iterator lambdas, which were a huge factor in the final syntax choice of Iterator Function() throughout discussion of the feature. I think originally VB was going for the Async modifier and C# tried to go without. Originally C# was looking at exception filters using

catch (Exception ex) if (...) even though VB already had When but they came around.

VB was originally going to go with ProtectedAndFriend or Protected And Friend for what is now Private Protected (we even joked about calling it Protected Internal in VB since that syntax was free) but ultimately both languages ended up using the same keywords. Sometimes they do end up going the same way and other times, thankfully they don't.

Now it's also up to us, the community, to speak up and loudly if we think something's going through that doesn't look right and never let anybody take shortcuts on the language we have to live with. Sometimes I talk to my friends who use other languages and they say stuff like "Oh, that (completely arbitrary syntax) seems fine to me" and I'm like "You're an F# programmer. You won't have to live with it. Everything seems 'fine' to you!". the joint-policing approach by LDM and community is still working for us. I have considered writing something about this topic such as "When a modifier is a noun like Iterator versus an adjective like Overridable versus a verb like Overrides or Implements" but I don't think most people would get as much of a kick out of it as I might.

[pricerc]

I have considered writing something about this topic such as "When a modifier is a noun like Iterator versus an adjective like Overridable versus a verb like Overrides or Implements" but I don't think most people would get as much of a kick out of it as I might.

Actually, that kind of thing would be helpful, at least to explain why some things are the way they are, so that people don't expend a lot of energy suggesting things (e.g. keywords) that have already been thought of.