Visual Basic Community #250
Comments
|
@AdamSpeight2008 said:
I'm fine with a wiki here for this, if you convince me that's where people will find it. Are you interested in contributing to the documentation? It's OSS in GitHub and is one of the things considered for MVP. If you are interested in being an MVP and you want my suggestions, I'm happy to help. I offered to do that when I was in the community, and don't see a reason to change (I can't magically make someone an MVP. You make yourself an MVP, but I can help you not be overlooked.) |
|
Who is the Visual Basic community? Is it a few hundred people trying to do cutting edge stuff frustrated by a language that doesn't have as much support as C# and hundreds of thousands of people working on legacy apps they are afraid they will break if they change anything? (To reassure, I am not asking this question in the context of strategy, but in the context of how we build and support community) |
|
@KathleenDollard I can only speak for myself, but VB6 was the first language I learned, and despite having worked in C#, PHP, and C++ before, when I think of how something works, my mind thinks it in VB, and then I translate. So when it came to my hobby project... Visual Basic was just the most natural choice. (And the ability to convert everything to C# if the language gets abandoned is certainly a big plus.) Personally, I wrote a home automation controller slash personal assistant thing. It also now runs in my car. I am bad at programming, but my project is fun. ;) |
|
There is the classic joke
|
The sections will in time be filled with more information. |
|
@ocdtrekkie What platform (what .NET) did you use? |
|
Trust, stability, longevity, adaptable, empowering. I personally believe the biggest issue facing VB is it simply not working with Microsoft's evolving vision. That's a huge problem and in many ways is happening as we speak. The question is how do we future proof VB ? What levels of adaptability does it need to work and continue to work across the plethora of .net ? |
|
@KathleenDollard WinForms targeting .NET Framework 4.5.2 at the moment. My attempts to do things with WPF tend to end in failure, and it's not super dependent on UI to begin with. (I originally hoped to factor out the form entirely and make it a service, but the version in my car is super dependent on a textbox at the moment.) |
More on 2In fact, we are uniquely positioned to offer new features, especially those called "sugar." This is because VB's advantage (to beginners and pros alike) has always been its position as a concise, expressive, highly readable language. (Even from its BASIC roots. Think of our For loops vs. C-style for loops). Therefore, our devs love sugar, request sugar, and are very good at introducing sugar. More on 3If this cannot be done properly, then the next-best solution would be for .NET to allow inclusion of VB code in non-VB projects. That way, project templates and emitted designer code would be in C#, but we could write the app-specific code in VB. (This was being discussed in #211, but can most simply/feasibly be done with separate |
Speaking for myself:
Thank you...for this initiative. I think a lot can be done to build up the community. |
The "community" here on Github is the first group. Possibly the hundreds of thousands of maintainance-only devs you refer to indeed exist; they're just not active members of the community. That said, the more important questions are, IMHO:
...Only you have the answer to that. |
|
@bandleader Yes. I think addressing the issues of #211 is probably the most important thing to give VB an extended future. |
|
@Bill-McC I sincerely doubt that #211 will do anything in regards to giving VB an extended future. What we need to think on instead is what new essential language features to incorporate into VB proper, and which should take priority. The language mix-in concept of #211 is just too big a task to be practical. In the meantime, if one must employ another language for a feature which VB lacks, inter-operating with other managed code can already serve the need, and there are straightforward ways to either merge or embed DLL's from other languages into your VB assembly. |
|
@rskar-git See my response to @KathleenDollard above with the "three points of frustration" for VB developers today. One of them is the about not being able to use VB with newer project types whose developers are only support C#. On another thread, it was suggested that this could be solved by allowing VB code in C# projects. That way, we could use the existing C# templates, and just code our app-specific code by adding .vb files. -- Hence the reference to #211. 😃 |
|
@rskar-git What point is there adding new features when the language won't run there ? Point me to all the new open source VB libraries out there ..... (well at least I can hear the crickets... relaxing isn't it)
I've watched over the last decade and a half many if not most of the leading VB community slowly but surely abandon it due to the on going frustrations Kathleen talks about. Your proposal to think on new language features for VB without addressing the elephant in the room is a bit like saying what new features we need on WP10 or writing a new web app with FoxPro ;) The writing is on the wall, we need to adapt to survive not just plant a few more seedlings and prayers. And we need to stop following the leader, because all VB can ever be is let behind if it takes that approach. |
|
I may have said this before but the reason to need C# code in a VB project is to support things that VB can't or shouldn't support (unsafe comes to mind). As long as I can call all C# libraries (slice for example) I wouldn't need VB extended (much) but without support for unchecked it is difficult for most people (include me) to implement Hash and Roslyn's Hash routines are private and are spread through many files. Being able to have one line of C# code in my VB project solves a lot. Below is a simple example of where it would be extremely useful. |
|
@Bill-McC When @KathleenDollard said "Who is the Visual Basic community?", etc., I took that as a suggestion of two camps within it: One camp that is "frustrated", and the other that is "afraid". If I'm reading the mood right, it seems it's mostly the frustrated ones (people like us?) who now dominate "github.com/dotnet/vblang". A motivation for #211 is (as @bandleader has expressed) "not being able to use VB with newer project types whose developers are only support C#". But hanging hopes on any developments for #211 is a long shot at best. We've already heard from @gafter (Language Designer and Compiler Developer on the Roslyn team). I'm not holding my breath.
Please hear me out. The real path forward is in finding-out what level of effort it takes - and what obstacles there are - in adapting a C#-centric project into something usable for VB. I'd bet if one or a few of us VB'er types offered to do the adaption work, darn near all of them "C#-only" folks would cheer us on. I do see two pain-points: (1) usage of case-sensitive naming schemes to their public and protected identifiers (e.g. protected foo and public Foo); and (2) commingled checked/unchecked integer ops. Those two things really ought to be addressed via new language features for VB. The rest - such as operators not in VB, and unsafe code - can be handled with extending the library/framework and refactoring.
Yeah, I hear you, it's surprising that VBA gets more attention (if PYPL is to be believed). Yet from the start when VB was transitioned from its p-code/COM/native world into the new .NET one, it was very clear that C# was the center of attention. And it was a very disruptive time; the migration wizard was horrible. What we are experiencing are the ripples of those rocky times and decimated mindshare (e.g. from 2005, https://blog.codinghorror.com/the-slow-brain-death-of-vb-net/). But, if TIOBE is to be believed, VB (as in VB.NET) is still in the top ten. (Hey, for a brief shining moment in December 2016, VB was ahead of C#!) So it's not over. I'd say by about Visual Studio 2010, VB finally found some of its old footing again, and things got much better with Roslyn. And now here we are, discussing the future of VB on github! |
|
@KathleenDollard Our goals should be to provide the members of the Roslyn Languages proposals, that we see are potentially viable. If is accepted by them, a Proposal Pull-Request is submitted to them, where further development can happen. We should also be aware that not everyone on here may not have experience of corporation procedures and approaches (like Microsoft) to development. Thus may get frustrated, to what seem to them like too much bureaucracy, or the "on true way" of how things are done. We should never denigrate another's lack experience or desire to learn. Remember that our reason for this, may not align perfectly. Some may doing Visual Basic programming as part of the vocation, other for the love of the programming in the language. |
Regarding mixing languages
|
|
@KathleenDollard I've been following #211, and I have what to suggest there, but I decided to come here first, because it's not relevant until we have some transparency Microsoft regarding their plans for VB. Based on the activity in the repos, I am not sure if the issue is technical.
Some transparency would be wonderful; otherwise, we're just turning wheels. Thanks for your work on the VB language, and for championing its case (and that of the VB community) to the Roslyn team and to Microsoft. |
|
These are good questions, not just related to #211. I'll keep the discussion of #211 in that issue.
Like C# and .NET the deepest value of OSS is the early conversations, discussions and throwing darts at any proposal put forward, no matter who it is received from. This conversation should be broad ranging and embrace every person here. But as we move towards decisions, we need to give weight to the knowledge and experience of the people that designed Roslyn and have dedicated many years to maintaining Visual Basic. We will collaborate at many levels, including assigning a buddy for any proposal that is moving into the Roslyn code base. In the effort to create a new feature the act of writing the code for something as complex and carefully maintained as a major language interacting with a complex and evolving framework: the effort to write code is not close to the largest portion.
VB is not pushing all new advanced development strategies, at least not at the pace of C#. The goal is to push the right strategies. Where new strategies are not pushed, it is not because Microsoft wants C# to be the only language, but because the vast, vast majority of developers on new technology work in C# and when a somewhat advanced strategy was attempted (Razor), uptake was very low. Strategies that help VB developers in all new and old workloads (performance, maybe flagged enums, pattern matching, a fresh look at interfaces, etc) appear to have a broader impact on Visual Basic developers than advanced development strategies. Feel free to keep asking tough questions. |
And that's because it is only available for C# - yes again frustration. VB should be the language that enables you to do Rapid Application Development, build fast and stable applications in as less time as possible, When I look at new C# functions, I see a lot that make much more sense in VB than in C#:
And that combined with the fact that there are blogs about the future functions of C# and previews of the next version of C#, lots of example code in C# - but none of them for VB, gives me a bad feeling |
|
A highlight example is that Windows Template Studio just gained support for VB. If VB is the beginner language, this should not have happened, because Windows Template Studio makes far more sense for VB users than C# users. It should've been a VB first technology. |
First, let me say how awesome it is that the question is being asked by someone in charge of VB going forward 😄 Now, to answer the question from my personal viewpoint: I started using VB since the VB5 days. It is the only thing that has managed to keep my attention for 20 years straight while loving every minute of it. The only way anything can do that is if it vibes with your core personality. As as person, I WANT RESULTS BEFORE (OR IDEALLY WITHOUT) CEREMONY...and the thing that keeps me using VB is that this language really really gets that. So who is the VB community? I would say it is made up of people who:
The elimination or reduction of ceremony is the reason for VB's reputation as the ideal tool for RAD. It is also why people find it easier to learn...and it is also the reason for some negative aspects in cases where ceremony is required but people skip it. The word "ceremony" here refers to everything that is not considered core to the task at hand, so let me give examples of both. For RESULTS BEFORE CEREMONY the best example is the form designer seen in the early pre-dotNET days. You opened the IDE, created a new project and hit Run. There on the screen was a complete form, you could move it, resize it and close it all without writing a single line of code...all BEFORE THE CEREMONY of deciding what to put on the form and what code to write to make it do what you want. Compare that experience to the one for using C/C++ and you see why VB attracts people who just want to get the job done. To be sure the ceremony is important (knowing the internals of your tools makes you a better engineer) but VB give you option to get results FIRST and worry about the ceremony (the details) LATER if you were at all interested. For RESULTS WITHOUT CEREMONY there are so many examples and this is where VB really really shines. Noticed a bug in your running program and want to make a small fix? Just pause, edit and continue (no stop, build and restart required). Finished typing a line of code and want to move to the next one? Just hit enter (no semicolons required). Named your variable You will note that a good number of the "no/less ceremony" features are about TOOLING NOT LANGUAGES and at the end of the day that is what impacts our productivity as programmers (not issues of syntax where we can debate endlessly then all go back to using what we liked anyway). Microsoft understood this deeply when creating .NET and Visual Studio which is why it always sucks when one language gets tooling support before the others (e.g the whole Xamarin/ASP.NET Core stuff). So in closing and to reiterate: THE VB COMMUNITY IS MADE UP OF PEOPLE WHO CARE DEEPLY ABOUT TOOLS THAT ELIMINATE OR REDUCE CEREMONY...and for cases where ceremony is important (e.g. declaring your variables before using them) the VB COMMUNITY IS MADE UP OF PEOPLE WHO WANT BOTH CHOICES (e.g via Option Explict On/Off). |
|
For the question "Who is the VB community?", I can only answer for my self - therefor a short profesional biography, what I build, what I use and what I need to do my job. I started out as a hobbyist in the 80ties - using Sinclair ZX81 (when I was 12 years old), Spectrum and QL. I build LOB applications, complete ERP systems, system couplings, EDI systems and SQL Server performance improvement tools - all with VB.Net. The technologies that I most use are Winforms, SQL Server, Web services and Windows CE (my customers still use those devices). Because of the habit of Microsoft do introduce new technologies and drop them a few years later (examples: Lightswitch, Silverlight, Windows Mobile), I am always hesitating to adopt something new - first see if it will survive, because my projects have a lifespan of 20 years+. What I need is a stable system (VS2017 isn't really stable when used on a terminal server), |
|
To show a case how I think VB should work (in opposite to C#; VB should do things for you as a RAD tool): I want to write a file - i use the VB My class for it (and if you see the code, I suspect the My class was build by a C# developer, because I have to check and do everything myself): How it should have been (with a VB mind): |
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. |
Yes, but |
You can't return a Span with stackalloc'd array in C#. |
|
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:
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 :-D |
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.
However |
|
@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? |
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 ClassSo if I had a VB parser Public Class Parser
Public Function OnValue(span As ReadOnlySpan(Of Byte)) As Integer
' unknown
End Function
End ClassCan 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#. |
|
@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. |
This comment has been minimized.
This comment has been minimized.
|
@benaadams @Berrysoft the |
|
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. |
|
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 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 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 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. |
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 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.
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). |
|
Oh, and @DualBrain needs to become a meme now:
|
Performance of Span is great; but I think more interesting is its also a safer and easier to use construct than 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. |
I wouldn't advice using
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. |
|
@terrajobst I'm now a MEME!!!!! |
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 |
|
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.
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
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 😈 |
|
@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. |
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 😄
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 Earlier on in the discussion about
The crux of my comment is this: if 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 😆 |
That makes a lot of sense and taken to its logical conclusion it means two things:
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.. |
|
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). 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). or 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". 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. |
|
@terrajobst Possibly not the best person say this, given my past record. |
|
@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. |
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, Somebody has to do all of this; the "somebodies" will come from either of two groups:
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. |
|
@ zspitz
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. |
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. |
|
@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. |
and others
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?
The text was updated successfully, but these errors were encountered: