Visual Basic Community

[KathleenDollard]

I am all about community. As a community, we can improve the experience of Visual Basic programmers.

What does that mean to you?

How do we best do that?

[Nukepayload2]

@Berrysoft

Actually you can now use Span in VB like this:

If you turn off Option Infer, your code will throw an exception. Because ref struct can't be converted to System.Object. The VB compiler should prompt a compile-time error for this case.

[benaadams]

Not exactly. VB doesn't support pointers, therefore span code in VB is still safe.

It still isn't safe as you may have got the span from a C# program that stackalloc'd it; if you store that in the heap when you later update it you are randomly overwriting a different thread's stack space; which would be very bad.

[Berrysoft]

@Nukepayload2

If you turn off Option Infer, your code will throw an exception. Because ref struct can't be converted to System.Object. The VB compiler should prompt a compile-time error for this case.

Yes, but Option Infer is on by default.😁

[Berrysoft]

@benaadams

It still isn't safe as you may have got the span from a C# program that stackalloc'd it; if you store that in the heap when you later update it you are randomly overwriting a different thread's stack space; which would be very bad.

You can't return a Span with stackalloc'd array in C#.

[DualBrain]

I was considering not adding to this already extremely long thread; however...

In my mind, the most basic responsibility to hold Microsoft accountable can be summarized to that there should be an expectation that what ships "in the box" (for .NET) should all "just work".

"VB, C#, F# should be able to target (insert .NET technology stack here) and just work."

If it a technology stack doesn't adhere to the above statement... DON'T SHIP IT!!! (Span, I'm looking at you...)

Another key responsibility is that Microsoft "DOESN'T BREAK MY S#$T!!!!!".

This is, on it's own, is probably one of the hardest things to accomplish and, unfortunately as some have pointed out in this thread, means that VB will have to adopt new core language features more carefully (aka slowly). AND THIS IS OK!!!!

So what does this mean?

There is a serious shared mindset problem. So let me start of by saying the following:

"I don't use VB because others use VB... I use it because it's what I want to use."

And... as it turns out... there are indeed more people out there with the same attitude. This is a good thing. I'll add:

"I use VB because it is the BEST language."

If you are still using VB... you most likely agree. We need to stop be self-deprecating. We certainly don't need to be reiterating what the people who don't use VB say about us. NEWSFLASH: None of this is new. Everyone has been speaking about the demise of VB pretty much starting with VB 1.0. Oh wait... it started BEFORE that... BASIC has been "dying" since... oh, I don't know... 1964. Humans are "tribal" by nature... there is a natural tendency to classify groups of people in the "us vs. them" organizational structure. Reading through this thread, I've noticed something that is somewhat interesting (at least to me).

There are many commenting that are relatively new to VB. The newer seems to be more concerned the the overall public perception of VB. While those that have been around a while are less concerned about this and more concerned about Microsoft's ongoing support and the overall stability of not just the language but the underlying technologies that are touched.

I've reconciled the fact that, as a VB proponent, that I will continue to snubbed by some. Does that put me in a negative mindset... NO. The net effect for me is exactly the opposite. It challenges me to ask some key questions:

• If something "can't" be done in VB, is it worth doing?
• If it is "worth doing"... then figure out a way to "just do it".

Again... none of this is new. The same thought process has been happening (at least for me) for the past 30+ years.

I think one of the biggest things that is negatively affecting the VB Community is one of confidence (or the lack thereof). We certainly do not need to be constantly comparing ourselves to C#. This is not to say that we don't continue to innovate, I'm just stating that we don't need to constantly compare ourselves to just C#. We shouldn't be moving forward in lock-step with C# simply because it is the "cool kid". Conversely, C# should be more considerate to the CLR... understanding that there is, in fact, more than one language running on .NET. ;-) With that out of the way, we should stop allowing other developers to criticize our choice... our choice doesn't (and shouldn't) have to be their choice and the reverse should also be true. .NET provides us the BEST opportunity for this; if we want to be critical of anything, it should be that NO language should be able to dictate (break) this. With that said, if some innovation is done (regardless of language) that will be adopted and exposed through various Microsoft technology stacks... then I refer you back to the beginning of this post. ;-)

Not one to shy away from a potentially heated discussion with regards to VB vs. (WHATEVER); for many years I've been completely polite about saying "equal" or "just as good". Those days far are behind me...

There's so much more to say on this subject, so close with a few quotes:

"BASIC is the BEST computer programming language EVER invented!" -- Cory Smith "VB on .NET is a GREAT version of BASIC!" -- Cory Smith

:-D

[benaadams]

You can't return a Span with stackalloc'd array in C#.

You can however be called with a stackalloc'd span; either directly or via a delegate. All the languages interop with each other so the rules on Span are important.

Span<T> and Memory<T> are good for VB as they are much safer than ArraySegment<T> as they have enforced bounding on their window, which ArraySegment<T> doesn't have.

However Span<T> (and ref structs if they are included) must still stick to the stack only semantics; otherwise VB libraries that use Span<T> become invalid to use from other languages and VB programs become invalid to give Span<T>s to (including from the runtime).

[Berrysoft]

@benaadams I still can't see which scenario leads Span to unsafe. Here's my opinion: 1. Span doesn't only contains stackalloc'd array, but also common(heap) array. 2. If the method is called with a stackalloc'd span, the span is always valid. Can you show some code that other languages make VB programs become invalid with Span?

[benaadams]

I still can't see which scenario leads Span to unsafe.

If a Span is allowed to be captured in a class or regular struct field; then it can create an invalid program

Public Class Class1
    Private span As ReadOnlySpan(Of Byte) ' This is invalid

    Public Sub OnValue(span As ReadOnlySpan(Of Byte))
        Me.span = span ' and this must be prevented
    End Sub

End Class

So if I had a VB parser

Public Class Parser
    Public Function OnValue(span As ReadOnlySpan(Of Byte)) As Integer
        ' unknown
    End Function
End Class

Can I call it with?

public int ReadData()
{
    Span<byte> data = stackalloc byte[256];
    // ...
    return Parser.OnValue(data);
}

If VB just ignores the Obsolete attribute and allows the Span to be stored to heap; then the VB is not safe to call from the C#.

[Berrysoft]

@benaadams Of course the compiler can't allow to store a Span in the heap. It's my fault to treat it too simple, but it still not hard to allow using Span in VB.

[benaadams]

Of course the compiler can't allow to store a Span in the heap. It's my fault to treat it too simple, but it still not hard to allow using Span in VB.

I assume that's the hard bit; everything else should just work.

[WolvenRA]

Just wanted to give a big KUDDO's! to DualBrain... I too am sick of the bigotry spewed by the C# fanatics. I also use VB by choice. I much prefer it to any curly brace littered language... but that's just my preference. If someone else likes curly braces, go ahead and use that language. I don't care what you use, why should you care what I use? Like DualBrain said, maybe it's the tribal nature of humans... but I would hope most programmers are a little bit smarter than that.

[ericmutta]

@benaadams @Berrysoft the Span<T> discussion seems to be very detailed and could probably use a seperate issue to get full treatment there without making this very long thread even longer :+1:

[terrajobst]

@WolvenRA

I understand this is passionate subject but please don't use wording like "I too am sick of the bigotry spewed by the C# fanatics". While you didn't accuse anyone of anything, it's a direction that isn't productive and is ultimately not helping you to convince anyone either.

[terrajobst]

@Berrysoft @jmarolf

The fact that a type is in .NET Standard doesn't mean that all languages are expected to support it. We can slice the BCL in only so many ways and cross-platform, size, app-models, and low complexity are also desirable traits.

From the start, .NET has had the notion of the CLS (Common Language Specification). Some types, such as unsigned types, weren't included. We're trying to make sure that we don't introduce new scenarios that require the use of Span<T>. That's partially because VB doesn't support them but also because many languages also aren't. And even in C#, Span<T> is somewhat of an advanced type with additional constraints (specifically the ref-like behavior). So everyone wins if mainline scenarios can be achieved without them.

You might think "hold on, your team added a ton of APIs that only support span". That is true but none of them allow you to do something that you can't already do (like all the new APIs around encoding, parsing, and JSON are span-based alternatives to the existing APIs such as Encoding, Parse, and Newtonsoft.Json).

In a sense, spans are very similar to how we deal with pointers in the BCL. Virtually anywhere where we support them, we also offer ways that just involve string or byte[]. And in the cases where we only accept pointers you're already into the weeds of unsafe/low-level interop. Span is very similar. We had a few instances where we violated this. For example, we added the new Path.Join() method that only took ReadOnlySpan<char>. We've since then fixed that by adding overloads for string.

So VB shouldn't be concerned that it loses the access to core functionality due to span. But of course, supporting it would allow developers to push the envelop more in terms of performance, but the question is whether that's an interesting angle for the VB customer base. That's a decision for @KathleenDollard and the VB community.

[terrajobst]

@dualbrain

"VB, C#, F# should be able to target (insert .NET technology stack here) and just work."

If it a technology stack doesn't adhere to the above statement... DON'T SHIP IT!!! (Span, I'm looking at you...)

I agree with you that the product needs to be self-contained but considering the size of the languages and the framework we can't test each and every combination of features and languages. We're trying extremely hard to be mindful when designing the languages and the key exchange types in the BCL but we make mistakes.

However, we explicitly allow certain scenarios to not work in certain other scenarios. Otherwise we'd design the lowest common denominator, which, considering how many scenarios .NET supports, wouldn't be useful. The trick, if you will, is to make sure that (1) it's not the norm (2) it doesn't hamstring mainline scenarios and (3) customers have a way to reason about this.

For span, see above. I think we've struck a reasonable balance between these goals.

"I don't use VB because others use VB... I use it because it's what I want to use."

I agree a hundred percent. Language choice is a very personal thing and it's hard to explain why one likes some languages and not others. I, for one, cannot stand reading code that involves a lot of words over symbols; I found it too taxing. That's why I liked Object Pascal more than Basic and why I liked C# more than Object Pascal. At the same time, I prefer productive environments over others that make me write a ton of code with my bare hands. That's why I preferred Delphi (Object Pascal) over Visual C/C++. And since .NET felt as productive as Delphi but offered more features I jumped on that as soon as it came out. And I've been there ever since.

At the same time we cannot ignore market trends. While individuals have preferences, so do groups. And that's where we have to realize that not all preferences are created equal. There are probably some people that would prefer to write .NET code using Hyper Card. But we can't invest in a product that has a maximum market share of 5 people.

Of course the market share of VB is hundreds of thousands of people -- that's a customer base many other companies would dream to have. So it's not like VB isn't worth investing in. But the resources are split between C# and VB and it's not possible for us to invest in both equally because it just doesn't make sense from a business point of view.

Oh wait... it started BEFORE that... BASIC has been "dying" since... oh, I don't know... 1964.

Agreed. I've never understood the argument of age. LISP is around forever and is alive and kicking. So is C. Just because something is old doesn't mean it can't be a good concept. Look at Unix. The architecture, tools, and languages are around for a long time. And yet there is a growing set of young people finding it attractive and swear by it. Whether something is desirable or not isn't decided by fiat, it's decided by the people using it (or not).

[terrajobst]

Oh, and @DualBrain needs to become a meme now:

[benaadams]

So VB shouldn't be concerned that it loses the access to core functionality due to span. But of course, supporting it would allow developers to push the envelop more in terms of performance, but the question is whether that's an interesting angle for the VB customer base.

Performance of Span is great; but I think more interesting is its also a safer and easier to use construct than ArraySegment<T>; as ArraySegment lets you access the full array rather than only the window it specifies, and you always need to add its .Offset to any element access, and check you are in the window against .Offset + .Count.

Additionally ReadOnlySpan allows intent to be communicated in an api far more powerfully than Array and without the performance hit of IReadOnlyList. Its the variant of array that has been missing for a long time.

[terrajobst]

Performance of Span is great; but I think more interesting is its also a safer and easier to use construct than ArraySegment<T>

I wouldn't advice using ArraySegment<T> for productivity or correctness; I'd rather create separate arrays. Of course, this isn't as performant, so yea :-)

Additionally ReadOnlySpan allows intent to be communicated in an api far more powerfully than Array and without the performance hit of IReadOnlyList.

Totally fair. I'm mostly being tongue in cheek but some of the safety that span provides you pay for with complexity due to the ref-like requirements. The scenarios we've optimized span for is more in the realm of systems programming where the alternatives would be even more complex than span. But many higher levels don't have those requirements and for them ordinary arrays and potentially copies are working fine. It's all about balancing.

[DualBrain]

@terrajobst I'm now a MEME!!!!!

[ericmutta]

@terrajobst: Of course the market share of VB is hundreds of thousands of people...

I have always been curious about that estimate (I don't dispute or agree with it either way because I simply have no data). As far as I can tell, everyone who does VB/C# does so from within Visual Studio, which Microsoft owns. Couldn't Visual Studio just count the number of people who use it for certain projects and report that figure daily to a public site we can all review? I imagine such data would be incredibly useful to a wide audience (not just the .NET language design teams).

For example, I would be really interested in having Visual Studio check how many VB projects out there with more than 1,000 lines of code are using Option Strict Off. If the number is "almost zero" then we can do away with that and greatly simplify the language so that the semantics of new features are easier to evaluate and implement for VB (especially for stuff like Span<T> which should ideally be cross-language because it is touching the BCL).

[terrajobst]

There are lot of problems with releasing data like this publicly. For starters, the data itself is valuable because we use it to make business decisions. And we have competitors.

But even if we did: it's very hard to measure the thing you care about accurately. I've spend a lot of time collecting API data, usually via static analysis but internally we also use other means to gather usage stats (e.g. crash dumps, profiling first party apps etc). The all have different biases. You'd be amazed how hard it is to measure things like "users" because we take privacy extremely seriously. We don't want to collect personal identifiable information (PII), partially because of compliance reasons (e.g. GDPR) but also because it's a business risk when this data is handled improperly. We have quite a bit of telemetry from things like VS but you very often cannot measure the exact thing, so you have to approximate by using other data points you then use to infer the thing you actually want to measure. And sometimes you can't even do that so you get an upper or lower bound. So we're not deliberately vague when we give estimates.

In other words, interpreting the data is hard. Internally, we have data scientists with a lot of domain knowledge that help us to get into the ballpark. But there have been cases where people looked at data and came to completely wrong conclusions that the data simply doesn't warrant. Thus, releasing this data without significant investment on providing guidance on how to read this data would be irresponsible too. So yeah, it's unlikely to happen.

For example, I would be really interested in having Visual Studio check how many VB projects out there with more than 1,000 lines of code are using Option Strict Off.

This a perfect example of something that is hard to measure. Sure, it's easy to write code that precisely measures what you're asking, but we can't hard code specific data collectors whenever someone has a question like that. So we collect generic data points. I'm not working in VS, so I don't know what we're actually collecting, but you can imagine that we don't actually collect the LOC but the bucket (e.g. <1k, 10k, 100k, 1m, >1m etc). We for sure don't collect source code but AFAIK we also don't collect telemetry on project settings so things like Option Strict Off might be even harder.

If the number is "almost zero" then we can do away with that and greatly simplify the language so that the semantics of new features are easier to evaluate and implement for VB (especially for stuff like Span<T> which should ideally be cross-language because it is touching the BCL).

Now this is an interesting one. While your assumption sounds reasonable it's problematic and a mistake virtually all PMs at Microsoft did one time or another. Just because something is rare doesn't mean it's not important. In .NET we strive for a linear learning curve (meaning simple things should be simple and more complex things possible, ideally with an increase in cost that is proportionate to the value you can realize). This is hard. Sometimes you need to cut some advanced scenarios in order to avoid causing too much complexity for mainline scenarios. But sometimes everyone has to pay a little, even in scenarios where it wouldn't matter, to keep more advanced scenarios possible.

I've zero data to back up my claim but here I go: a programming language that is extremely optimized for < 1000 lines is probably not going to work at all for projects with 50kloc. I mean we all know JavaScript, so 😈

[DualBrain]

@ericmutta One major flaw in "measuring" is simply how can you accurately measure for VB? For example, how many people use the compiler (command line) shipping with the .NET Framework. What about those that are using the Mono version of the VB compiler (not Roslyn)? Taking this a different directly, the likely-hood of anyone getting hit by lighting is very, very, very small. However, if you are that person that got hit by lighting... it 100% sucks! Removing things from the language as long as there is at least a single person utilizing it doesn't make sense. It might not affect "many", but the few will be seriously impacted by it.

[ericmutta]

@terrajobst: ...And we have competitors...compliance reasons (e.g. GDPR)...

Good point! When happily discussing these things to our collective heart's content on an open-source platform, it's very easy to forget that this is a business and there are people, budgets, laws and jail :smile:

@terrajobst: Just because something is rare doesn't mean it's not important.

I totally hear you. For example VB's late binding may not be something people (should) use frequently but it is important. When you need it you probably really need it. However, this particular feature (late binding) seems to be a black hole sucking the innovation out of VB's future to the point where I am wondering if it is really really that important.

A good example is the .NET Standard 2.0. For a while in the past, you couldn't write VB code targeting that version (while C# could). And then you guys did something and it became possible. I think it was done by embedding portions of the VB run-time, which @KathleenDollard indicated is being ported to .NET Core 3 now.

VB-isms like late binding are implemented via that run-time. Many of these VB-isms are legacy stuff from VB6 which you can completely live without because they have counterparts in the BCL. And for sure they are important to someone. But 20 years later VB is still dragging its run-time forward like a chain around its neck. It means I can use stuff like On Error Resume Next and Option Strict Off but at the heavy heavy price of being unable to do stuff like write code targeting .NET Standard 2.0 as was the case in the near past.

Earlier on in the discussion about Span<T> @jmarolf said:

...VB unfortunately is more complex than F# in this scenario as we need to think about VBs unique binding semantics.

The crux of my comment is this: if VBs unique binding semantics make it "unfortunately more complex" to implement new stuff for VB, then isn't now, after 20 years, a good time to review whether we really need those (legacy) semantics?

Personally for example, if I was told "you are going to lose late binding support, but because the language is now simpler, we are going to innovate faster and support more scenarios", I would be very happy to lose late binding support.

Most of the legacy stuff has a viable work-around in VB itself or the BCL. Losing it may hurt but it is not fatal. But what do you do when you are told new features/platforms are not supported for VB? You either have to switch languages (a drastic change given how religious one's choice of language is) or just give up programming entirely and become a grumpy old git :laughing:

[ericmutta]

@DualBrain Removing things from the language as long as there is at least a single person utilizing it doesn't make sense. It might not affect "many", but the few will be seriously impacted by it.

That makes a lot of sense and taken to its logical conclusion it means two things:

1. No feature (legacy or otherwise) will ever be taken out of VB in the future. If a given feature (e.g. late binding) brings with it complexity that makes it easier to add features to other languages when compared to VB, then we can expect little to no innovation for VB. Forever.

2. Since removing stuff is near impossible, you can bet that adding stuff will be near impossible because once a feature is in, it is in forever. This probably means it will be a long long time before anything we suggest in this repo will ship (if ever).

The above grim reality probably explains why in the very long release notes for Visual Studio 2019 you can find mention of C#, F#, C++, XAML, TypeScript and JavaScript. But not VB.

One may be tempted to think that there's a secret cabal of people "holding VB back" or that Microsoft has "lost interest in it", but I have come to the conclusion that the reality is less exciting: VB is not evolving as quickly as everything else because it is really hard to evolve it.

I'd be keen on hearing @KathleenDollard's vision on resolving this "checkmate" scenario that VB finds itself in so that over the long-term, VB can keep evolving and thriving..

[DualBrain]

There is mention of F# throughout this thread and how quickly it is evolving compared to VB. I think that is a great area to have a conversation. First, let me express that I'm not any sort of an F# expert and that I'm not totally keyed in on all of the community as a whole. However, from the outside (and my limited involvement in the past during a single hackathon) I think there are some key takeaways that I'd like to share.

From what I understand there are very few people at Microsoft that do the "hands-on" work on F# full-time; I've heard that there it's more of a "management" structure that is on the Microsoft side and most (if not nearly all) of the development work is done by the F# community. (If there are any F#-focused people reading this, please feel free to help clarify.) Regardless of what the actual makeup of this structure, it's clear that it's the overall community that drives F# forward by actually doing the work. This is AWESOME! But please don't confuse / conflate F#'s evolution as something that is somehow taking away resources from VB. Because of how that work is being done, it literally has nothing to do with VB. Additionally, if you even mildly follow along you'll find that F# suffers from a bit of "me-too"-isms every once and a while with regards to "stuff showing up in C#" or "stuff supporting C#" before it's available in F#. The difference is that it typically is the community that fills that void. Again, nothing to do (for the most part) with Microsoft.

XAML has nothing to do with VB. That's a completely different stack. However, because you bring it up... however, VB does have something C# doesn't... we can do things with XML (which XAML is) far easier than C# can.

JavaScript was, is and continues to be a mess... thank you TypeScript for stepping in. ;-)

C++… have you ever developed anything using C++ that you had to actually ship and continue to maintain. I'm not a C++ expert... but I can certainly tell you that my experience that I do have with it just, frankly, ticks me off. EVERY single time I've had a project that was necessary to be in C++ (not to be confused with C) and a new version of the language, environment, tools was released queue the ensuing nightmares of WTF head scratching errors. As such, I avoid it as much as possible for any projects.

This leaves C# (as your last comparison). NEWSFLASH! Some of the work that you are describing and attributing to Microsoft is actually being done by the community. Sure, the core stuff is being done by Microsoft... and you know what... that is true of VB.

So let's talk about VB.

You mention Late Binding as being something that is holding back VB. Or that it's the "runtime". It's none of these and yet all of these. Let me explain...

There is a conversation regarding adding "pattern matching" to VB. This talk has been going on for some time. Which goes to exactly what you are saying. However, I think it's a good thing that it's taking time (I'll come back to that more in a moment for an actual historical example).

    Select Case Today.DayOfWeek
        Case DayOfWeek.Monday,
                 DayOfWeek.Tuesday,
                 DayOfWeek.Wednesday,
                 DayOfWeek.Thursday,
                 DayOfWeek.Friday
            Dim message = "Get to work!"
        Case DayOfWeek.Saturday,
                DayOfWeek.Sunday
             Dim message = "Funtime!"
    End Select

Notice that we have message scoped within each Case. This is not something that C# does. Why do I bring this up? Simple... let's look at an alternative (that doesn't currently work).

    Dim value As Object = Foo
    Select Case value
        Case Is Bar
            value.OnBar
        Case Else
             value.OnFoo
    End Select

or

    Dim value As Object = Foo
    Select Case value
        Case v As Bar
            v.OnBar
        Case Else
             value.OnFoo
    End Select

The more I think about pattern matching in VB, it seems to me that we should probably have it two different ways. One that is totally implicit and the other that is more explicit (like C#). To me doing it the "same as C#" just doesn't feel right. I feel that in 99% of the cases, the reason why you would be doing this would dictate the first example being the more appropriate approach and (most importantly) doesn't force us to create garbage (meaningless) variables to get the job done. So why do I point out the "message" example above. Each Case has it's own scope... so this means that we could indeed have the implicit-ness I show. If we just rushed head first into implementing this in a "me too" fashion... I'd argue that VB would continue to evolve where it felt less like BASIC and ultimately what would be the point in that? In other words... if we could only have one... I'd choose the first option. If we can have both, AWESOME! If we could only have the second one... I'd rather not have it. (Please see further down as to why.)

For a little history... let me share a personal story.

There was a time when you always had to do the Get/Set on a property (the dark ages). I remember clearly that the conversation for making this easier (eventually being called Automatic Properties) was initially taking place in the "VB community". I obviously was a huge fan for the addition of this. Fast forward a little bit. I was pretty "hurt" when the feature was delivered and available C# developers leaving us VB folks out in the cold. (Amanda, you failed us! - don't stop reading) Fast forward a little bit more. I have to say that although the waiting part sucked, when it did arrive in VB... it is a FAR SUPERIOR implementation! (OK, Amanda... I was wrong.)

Let me share another story... it took me talking about something for what I believe is over 8 years. In my mind it was super simple. Others in the community thought it was simple as well. The difference is I'm a big fan of NOT CHANGING the language if we don't have to. My personal first rule of language design is to not add any new keywords. I am in no way criticizing Lucian or @AnthonyDGreen... when they were "in charge" of VB it's a hard task... it's just not that simple no matter how much we think it might be. In the end, it was done and it didn't require any new keywords! That took 8 YEARS to not add a keyword, to not make any changes to the language yet make the underlying improvement! (Thank you @KathleenDollard for helping it get across the finish line.) Imagine if it was a new keyword and there was inconsistencies added to the language because we rushed to the solution. (Thank you Lucian and @AnthonyDGreen for ensuring that a conversation had time to take place.) The long-term gain would net us a total loss... thus my first rule. ;-)

So one final history lesson. The single most action that has critically fractured the VB community was "the move to .NET". And it wasn't the move to .NET that caused the fracture... it was literally the idea (and subsequent) actions that forever damaged the image of VB. This was the notion that a few influential people who felt the same way as some do now that it would be perfectly OK to discard "the old way" in favor of the "right way". We still haven't recovered from this. Even after a lot of this damage was repaired from a technical point of view by around 2008... those that were displaced, forgotten, hurt by all of this wouldn't even give the improvements a view. This, of course, finally gives a window to VB competitors to swoop in and save the day. This is something that we absolutely cannot survive through a second round. We just can't.

Looking to the future... the MOST important thing in my mind is one of growing the VB community. This means we need to bring in new people and we need to be able to keep them. Does this mean that we do this using Span? I don't think so. Does this mean that we need to be in constant "Me Too" mode? Again, I don't think so. It's about figuring out what VB does well and we continue to do that. We need to look to our history and figure out what made us great (and equally despised) in the first place. Bring on the VB hate... the more people "hate" VB because of how BASIC it is... simply because we are catering to beginners and it is all-purpose... the ease of it's use the elegance in that... then we are doing something right. We need to stop shying away from the word BASIC... we actually need to start looking more closely at it.

Beginners - yes... the barrier of entry should be low. Additionally, because we are catering to beginners, this means that the more advanced we are... the simpler the more common tasks are meaning the less work we need to do. Just because we embrace beginners doesn't mean that the product can't be advanced. Let me quote the creators, "Advanced features have to be added so that, if there was a price, it was paid by the expert, not the novice." We think about all the features from the point of view of the novice; but that doesn't mean we don't do advanced when there basically isn't any other way to "make it simple". All-purpose - come on!!!!! Seriously... VB combined with .NET! This should be our sweet spot. ;-) Symbolic Instruction Code - Verbose... we got that one covered.

We constantly get criticized for the word beginners... and that's OK. What is not OK is that we are not living up to it! To me the things we need to focus on aren't the "advanced" features, but the simple ones. It's not the advanced features that are making my day-to-day development life better.. it's "the little things". (And, as it turns out, it's the little things aren't without their effort.)

We have a an already amazing language wrapped with amazing tools. The tools are were we can easily see advancements thanks to Roslyn. As for advancements in the language, we need to definitely do some introspection... not to remove / reduce... but to adjust so that we are living up to our name. With that said, if external forces dictate that we have to support feature x so that we can participate (consume assemblies) in the greater .NET eco-system... that's without question and is absolutely priority #1. If this can be done without changing the language... FTW!

Just try to keep in mind that language design is hard. Getting it right is even more difficult. It's not the surface area that is the problem... it's that the problem is getting it right is very hard.

[AdamSpeight2008]

@terrajobst Possibly not the best person say this, given my past record. I think Microsoft could help community members that are attempt to learn the Roslyn codebase. A rough understand of the codebase presumed, but also accept they maybe gap in their knowledge. As to foster competent contributors, so they can help maintain and provide features in the future. For example a Blocked Progress (Community) issue, say each month or so. Where we the community could ask for help, or information. Upon which the team then can assess them, then maybe provide blog / wiki posts, or provide a pull-request against their explaining an aspect of the code-base or fix.

[zspitz]

@DualBrain The implicitness you're describing -- if the compiler can know the narrower type of a referenced variable, allow using the members of that narrower type -- is not specific to pattern matching, and has already been discussed at #172.

Dim value As Object
If TypeOf value Is Bar Then
    value.OnBar
End If

[zspitz]

@ericmutta

VB is not evolving as quickly as everything else because it is really hard to evolve it.

This.

Every new feature added to any language requires a tremendous amount of effort in design, spec, implementation, documentation, testing; both for the feature itself, and for how it fits in with the rest of the language, technically and stylistically.

(I suspect -- no hard evidence -- that the VB.NET compiler does more in the background than the C# compiler does, to enable the developer to write simpler and more natural code (e.g. late binding, Select Case on non-constant, no null-checking required when raising events); this compounds the necessary effort.)

Somebody has to do all of this; the "somebodies" will come from either of two groups:

1. Microsoft employees
2. the language community

My understanding is that 1) the C# community is an order of magnitude larger than the VB.NET community, 2) Microsoft is after all a business, and must allocate resources in line with the respective size of the C# and VB.NET communities. There is less of a chance that all these "somebodies" will come from Microsoft.

But we as members of the VB.NET community can certainly contribute in this direction. PRs for the VB.NET compiler shouldn't have to come only from @AnthonyDGreen and @AdamSpeight2008 -- anyone can provide a PR or a specification. Admittedly, there's no guarantee of it being accepted; it might (nay, probably will!!) be discarded right away. But even a bad PR or specification will advance the sum total -- "don't do this because of X", "that is a bad idea; it doesn't go well with Y"; so now something else can be tried.

And testing proposed PRs is no less important, as is writing documentation.

Eventually, all this trial and error will move language forward.

[DualBrain]

@ zspitz

Admittedly, there's no guarantee of it being accepted; it might (nay, probably will!!) be discarded right away. But even a bad PR or specification will advance the sum total -- "don't do this because of X", "that is a bad idea; it doesn't go well with Y"; so now something else can be tried.

100% agree! And this shouldn't dissuade people from starting/having these conversations. It is hard. It should be met with EXTREME criticism. This is natural, expected and absolutely necessary. People don't have to be mean, mind you... but criticism has to be expected and we should all go into this expecting a "No" from on the onset. If you truly believe something is worthwhile, it will take time. I've already shared a personal story on this subject. I wasn't dissuaded, I persisted. I wasn't mean. I wasn't upset... I get that language design is hard that that there isn't an "army of developers" behind all of this.

I'll share that I'm still lighting a torch (apparently I'm like one of two people on the planet) that want's inline IL. Is it a good idea.... YES! Can I prove it? Sure... look at some other versions of BASIC. Is it going to happen? Probably not. And... that's OK.

[zspitz]

@DualBrain

And this shouldn't dissuade people from starting/having these conversations.

But my point is not just hand-wringing about the apparently immovable rock that is VB.NET, or even talking about it; it's that we as the community can and should do more than just talk -- we can spec, we can implement, we can test, we can document; with the understanding that even though none of our efforts will be in the final version, they still have value by enabling the conversations that lead up to that version. (Witness the spec that prompted the LDM).

NB. My personal hope is for #172 and pattern matching.

[DualBrain]

@zspitz Doh! Good catch. (Not an excuse... I was distracted by my two year old. ;-) ) So, yes, I meant "should not dissuade". Also, I agree 100% (and am on board) with your latest post.