Hacker News Reader

Comment by clouddrover | Hacker News Reader

Sounds like Visual Basic will be a second-class citizen going forward.

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

I've definitely seen VB6 applications powering for example bank counter systems. This has been a while ago though.

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.

VB.NET should never have happened. It has only superficial similarity with VB6. It was sold as upgrade path from VB6 but that never worked.

Perhaps, but I think it offered people who didn't have exposure to C-like language syntax, an easier upgrade path for their own skills.

I was writing stuff in VBA and a little VB6. The move to VB.NET was made easier because of the synax similarities.

My move from VB.NET to C# was made easier because by then I understood the framework, and it was just a matter of learning the syntax differences.

Maybe that's not such a big deal with a lot more people having exposure to C-like syntax languages like Javascript.

I followed the same path. Muscle memory is a big deal. Muscle memory is what makes you productive. It’s why those syntactic things actually matter.

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.

I am more radical, .NET should never have happened, rather the original Ext-VOS idea with COM instead of trying to build on top of Java ideas.

VB6 was AOT compiled and used COM as its component model, C# should have been similar but for C++ folks, basically what .NET Native came to be.

However they really botched UWP execution, when it could have been the proper .NET reboot back to Ext-VOS roots.

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.

Absolutely. Saying this as someone who codes 100% in VB supporting applications that are 25+ years old.

Honestly, I couldn't be happier with the language strategy as I was wholly expecting VB to be discontinued.

.NET itself is about 20 years old. How are you supporting VB apps that are 25+?

They probably migrated some VB6 apps to VB.NET.

I don't see the contradiction. Visual Basic existed before .NET did.

Visual Basic is more than 40 years old. The .Net version of the language was released somewhere around 2002, if I recall correctly.

Reply on news.ycombinator.com