Visual Basic had already become a second-class citizen fifteen years ago, when I worked on its compiler team. All the actual design work happened in the C# world, and our job was just to tag along and mimic whatever they had come up with.
I had taken the talk of "co-evolution" at face value before going to work there, but after seeing where devdiv actually put its time and attention, that was clearly just a PR story meant to keep VB users comfortable while their language faded away.
> All the actual design work happened in the C# world, and our job was just to tag along and mimic whatever they had come up with.
What's the unique guiding philosophy or use case of VB that would justify developing bleeding edge new language features in VB first? Maybe I am just being overly critical here but I just don't see how the use cases which VB accommodates would benefit from getting new features before C# gets them, and the divergence would create unnecessary pain across the whole ecosystem
I always saw Basic as the language for non-professionals who wanted to create their own software: hobbyists, amateurs, small business owners, people who have an idea and want to automate whatever it is they're doing, but aren't trying to write code for a living. C#, by contrast, is a proper mainstream language for professional programmers.
Replace basic with Lua and read your line back. Just because a language is simple doesn't mean it can't have industrial purposes by whatever gauge you measure things. Theres a bunch of things I wouldn't use basic for just the same with C# and "popular-language-here".
Probably the most used programming language is VBA or maybe the Excel macro if you consider that a language.
Did that remark come across as a criticism? I did not mean it so; distributing the power of programming as broadly as possible has always been a central value in my career, and that's why I joined the VB team in the first place. I meant that while it made sense for cutting-edge language development to happen elsewhere, I had thought that VB would have been a great place for work on improved human factors. How can we design the interfaces for this complex system so that people who do not yet have (and may never gain) a strong mental model of its architecture will nevertheless be able to improvise their way to success? That's where I thought the value of VB was.
> while it made sense for cutting-edge language development to happen elsewhere, I had thought that VB would have been a great place for work on improved human factors.
Thanks for clarifying, this makes sense to me and it's unfortunate you didn't get to see this through to fruition
It has been for a very long time, and that's a reasonable approach IMO.
I say this as someone without most of the usual prejudice against VB; I used to work in a large codebase that was half VB.NET and half C#, and didn't mind VB. VB was a little more verbose for some things, but after getting used to the syntax the developer experience was basically the same in each language (yes, with a few small exceptions like XML literals).
Ultimately, that's the problem with VB; it's not different enough from C# to really justify significant investments in 2023. There are some die-hards who really like the VB syntax but they're growing ever rarer.
I disagree. It only broke backward compatibility with VB6 when VB6 didn’t make any sense. Like byref arguments by default, or the useless “set” keyword, or collections being inconsistently 0 or 1 based, stupid constraints on what types you can expose as a field or property in a class, or no way to distinguish empty strings and null. Having done the transition from VB6 to VB.net, yes there were a few things to learn but that was the only way to move on from legacy design choices.
Honestly, most people still using Visual Basic at this point probably aren’t itching for new features. Stability is a feature itself when it comes to legacy code.
