Visual Basic (both of them) still exist, but their use has dropped dramatically through some big changes:
* "Visual .NET" (aka "Visual Fred" http://catb.org/jargon/html/V/Visual-Fred.html ) was released by Microsoft. This was an incompatible language confusingly also called Visual Basic. I don't think Microsoft realized how angry this made developers and businesses, who were being asked to spend hundreds of billions of dollars (USD) to rewrite code just to keep the same functionality. Before that time, many thought that Visual Basic's wide use gave it a kind of "herd immunity". I don't have numbers with me, but I remember that years later that a study found that some were sticking to the original Visual Basic (even though it was no longer supported), a few had moved to Visual .NET, and many other had abandoned Visual Basic entirely (some to C#, others beyond). In short, the Visual Basic community was split into multiple communities, and anyone using Visual Basic would have to worry about either lack of support or yet another harmful change.
* The rise of the web and of platforms other than Windows (including Android, iOS, MacOS, Linux). Visual Basic is fine when you send files via sneakernet to another Windows user. Now people want to access through their web browser, smartphone, etc. If you have a website, anything can access it (as long as they have the permissions), and you don't have to worry about synchronizing data changes the way you do if people make changes on their local device. Most of the simple "fill in a form" kinds of applications that Visual Basic was used for are more sensibly web applications (server side or client side).
Visual Basic is still used. And yes, I think there could be better tools for developing software. But as best as I recall, that's how we ended up here.
As someone who was writing Visual Basic.NET back when it came out, there was no upside to it over writing in C#. VB's original sweet spot was for writing small scripts and apps in Windows, and it was the only language available. When the .NET line came out, you could do the same things in whichever language you wanted. When new tasks came in, I started defaulting to C# for that reason. I don't think anyone actually prefers VB syntax. C# has a pretty robust community around it now.
> When new tasks came in, I started defaulting to C# for that reason. I don't think anyone actually prefers VB syntax. C# has a pretty robust community around it now.
Which was your experience because you knew C. VB appealed to people who were not programmers (or not very good ones like me). Microsoft effectively tossed an easy to learn procedural language in the trash and said "go learn all these advanced CS concepts or stop writing stuff" to which most hardcore VB users chose the latter.
While maybe that's true, that doesn't map to my experience very well. After QBasic, I wrote a lot of Visual Basic 5 and 6. I had poked at C, but would not say I knew it, and had never done anything useful in the language. But I did exactly one thing in VB.NET before trying C# and realizing that it really did encapsulate and present a better way to think about code. It's not perfect, but it's much, much better--and in that era, .NET 2 or so, it was significantly more ergonomic and had better tooling than Java or PHP, the other two languages I learned about contemporaneously with C#.
Maybe there's a mass cohort of people who were simply not going to learn something new, but in the light of most of twenty years hence, I think that they made the right call.
I've worked with a ton (too many) VB programmers by virtue of the work that I do (UI automation).
My experience all suggests that pure-VB (even .NET) is a treacherous dead-end, because it doesn't scale in terms of complexity and project size, and the point at which is stops scaling is often unrealized by its developers.
- VB(.NET) is amazing for small, simple gadgets.
- VB(.NET) is terrible for large or complex systems.
The problem is that VB is likely to be the only programming language that developer knows (moreso than developers in other languages).
Consequently, when they reach the end of the reasonable VB road... they will NOT say "Oh, I should learn C#."
They will say "How can I make this work in VB?"
And that's when you start to get business-ending unsupportable messes of spaghetti code that just barely work, on a good day.
Give a person only a hammer, and they'll find a way to make the entire world a nail.
> VB(.NET) is terrible for large or complex systems.
This doesn't make sense to me. I worked in a 50/50 VB.NET/C# codebase for years and while I don't love the VB syntax, the two languages were 99% interchangeable. Nearly anything you can do in C# you can do in VB.NET, and vice versa.
Lol, it doesn't scale because of the quality of the programmer, not because of the language. There may be some self-selection there but it isn't because of the language or tooling. Any "too easy" language brings these comments. People complain about MATLAB too when in fact there is nothing wrong with it or VB. Of course you can abuse both for purposes they are not meant for.
> VB(.NET) is terrible for large or complex systems.
C# and VB.net are semantically 100% identical. Only difference is surface syntax, like begin end instead of curly braces. It scales exactly as well as C#.
> - VB(.NET) is terrible for large or complex systems.
I can't say I agree with this. My experience has been that developers who write things in VB tend to be self-taught and don't know how to scale up small gadgets into large systems.
You may be confusing Visual Basic .NET with Visual Basic 6 and its predecessors. C# actually predates VB.NET by about a year.
VB.NET may be syntactically similar to VB6, but under the hood they were so different that migrating projects to VB.NET essentially meant a complete rewrite.
Visual Studio had a built-in migration utility which could get you 80-90% there. However if the original VB6 was spaghetti code written without Option Strict and Option Explicit enabled you had much bigger problems.
The biggest breaking change was the removal of the global Printer Object so any printing code needed a complete rewrite.
My recollection is that the migration tool was really just a tool that would fill your VB6 code with comments telling you that you had to rewrite stuff. Trouble spots were largely related to error handling On Error Goto and error handling blocks had to be refactored into proper Try...Catch blocks, which affected a lot of code, and another trouble spot was all File I/O had to be rewritten/redone, same with any drawing code; Resource files had to be recreated, etc; I don't even think it could load the FRX files but I might be misremembering. I felt it simply wasn't worth even bothering to try to directly convert to VB.NET, and since those programs I wanted to move forward I had to pretty much rewrite anyway, I decided to use C# instead and just make new versions.
The migrated VB6 code I saw back in the era when VS2003 came out was a thin glue layer over some compiled DLLs. So the result of using the converter was a thin VB.NET wrapper around very outdated, vulnerable, unsupported third-party code.
Maybe other shops had a lot of pure VB6 code, though.
Visual Basic is one of the best arguments for open source and community ownership in the history of computing, IMO. Microsoft's decision to tank it was hugely painful for companies that had made major investments in it -- no company should make that kind of investment in a proprietary platform that can be killed off by a single company and not forked and maintained by others.
I totally agree with you, but unfortunately the lesson was not learned. Now in the back office you see "standard" software with their own scripting language, e.g., APAX in Salesforce, or ABAP in SAP. Which is seen as a step forward, which it is architecturally, but not the point that you rightfully mentioned. On the other hand, all code is cyclical, if someone were to make it in Python, that would have to be rewritten, too. At least if you go the Free Software way, you're free to choose when.
Lol, my first programming gig as a teenager was performing a VB6 -> VB.NET "upgrade" of a 200K sloc legacy desktop application, which obviously ended up being a total rewrite. Everything in my career since then has seemed easy in comparison.
If this was mine, I'm so sorry :) Just kidding, I actually know my VB6 code is still running in prod.
VB6 did let me learn to program very valuable utilities from scratch, with practically no programming experience. I probably owe my entire career to it and VBA. I took a C++ course once and it nearly turned me off of coding completely. VB6 saved me.
I learnt VB6 when I'm still 10 years old and all seems so simple and magical. Then I encounter "Visual Basic" again in high school and it's almost unrecognizable with all the C# nonsenses. I still don't enjoy programming GUI like I was in VB6.
I was a hobby VB developer at this time and I abandoned it shortly after VB.net without really realizing why. I also abandoned Windows completely shortly thereafter.
The main thing that killed me was the size of the files that you had to distribute when you used VB.net. No one had the .net runtime early on and it was absolutely massive. I was paying for outgoing data by the gigabyte back then and our connections were much slower.
If Microsoft had simply ported Visual Basic in a compatible way to .NET history would have been very different. What's the point of the common language runtime when all the common languages are just reskinned C#?
This was a major missed opportunity for Microsoft -- if they had brought Visual Basic proper in .NET it would have given hundreds of thousands of applications a smooth upgrade path into modern development. It also would have given the entire Office suite an upgrade path from VBA to .NET -- something they've still not managed.
To this day, our office still has one critical commercial 3rd party application written in Visual Basic. It's replacement is, of course, a web app written in .NET.
> It also would have given the entire Office suite an upgrade path from VBA to .NET -- something they've still not managed.
> To this day, our office still has one critical commercial 3rd party application written in Visual Basic. It's replacement is, of course, a web app written in .NET.
seems like they did, they just didnt care if it remained in office, and it seems the author didnt care that they got screwed over by microsoft :)
Yeah, as someone who worked somewhere that had a VB6 project: VB.net was only at all useful as a stop gap between VB and C# and a barely useful one at that.
The language as it stands is fine and interop with .NET means it is a decent choice to use, outside of C# just having a bigger user base from a "how easy can I hire devs" standpoint.
I wrote Dts package scripts in Vbs but had primarily used C# for application development. When Ssis came out with Sql Server 2015, they only released Vb.Net for scripting components. It wasn't a natural transition from Vbs -> Vb.Net so we ended up writing libraries in C# and using those in Vb.Net. Brutal.
I was using Visual Basic 6 for throwing GUI's together. I loved how it loaded and iterated in one second on a 400MHz P3. Then, we got Visual Basic .NET. It took forever to start up. Then, it wasn't really Visual Basic. Then, iterations were slower.
It was going to be a rough trip. I figured I might as well learn something different so the headaches have more of a payoff. I stayed on Visual Basic 6 for a while before quitting it. I'm using Python now and it still doesn't feel as easy as VB6 did.
Great points. And in a tongue in cheek way, having reactive components you can attach handlers to fetch / redraw you UI .. is still there, it's just labelled vue or react ;)
* "Visual .NET" (aka "Visual Fred" http://catb.org/jargon/html/V/Visual-Fred.html ) was released by Microsoft. This was an incompatible language confusingly also called Visual Basic. I don't think Microsoft realized how angry this made developers and businesses, who were being asked to spend hundreds of billions of dollars (USD) to rewrite code just to keep the same functionality. Before that time, many thought that Visual Basic's wide use gave it a kind of "herd immunity". I don't have numbers with me, but I remember that years later that a study found that some were sticking to the original Visual Basic (even though it was no longer supported), a few had moved to Visual .NET, and many other had abandoned Visual Basic entirely (some to C#, others beyond). In short, the Visual Basic community was split into multiple communities, and anyone using Visual Basic would have to worry about either lack of support or yet another harmful change.
* The rise of the web and of platforms other than Windows (including Android, iOS, MacOS, Linux). Visual Basic is fine when you send files via sneakernet to another Windows user. Now people want to access through their web browser, smartphone, etc. If you have a website, anything can access it (as long as they have the permissions), and you don't have to worry about synchronizing data changes the way you do if people make changes on their local device. Most of the simple "fill in a form" kinds of applications that Visual Basic was used for are more sensibly web applications (server side or client side).
Visual Basic is still used. And yes, I think there could be better tools for developing software. But as best as I recall, that's how we ended up here.