Basic has been around for a very long time. There's BASIC, BASICA, GWBASIC, QBASIC, TURBO BASIC and maybe more variants that I'm not aware of.
But it was when they released Visual Basic that really made this a household name (so to speak).
The first Visual Basic (or VB as it's normally referred to) that I've used was version 3.0 running on Windows 3.1 environment. Without knowing anything about displaying a "window" and an "image", I was able to do it in VB in around 10 minutes. That's when I thought, this is what I should learn more about cause I can do more with less coding (not that coding is bad in itself, but minimizing coding only to the business rules would be ideal).
VB 4.0 and VB 5.0 later came along and these are the versions that most companies back then used to create their internal computer systems.
Even in the year 2009 there are still some codes that have been written in these VB versions, though most have been migrated to VB 6.0.
VB 6.0 was probably the most popular and best VB Microsoft has ever produced. Even now, several companies still use VB 6.0 to run their systems --- manufacturing and even financial systems.
But there is a big flaw (if we can it that) in VB 6.0 that made Microsoft decide to rewrite VB "from scratch" --- it's not fully OOP.
To someone unfamiliar with OOP, it stands for "Object Oriented Programming" where you design and build a system based-on or modeled-after a real-world object. Now, OOP has 3 major characteristics: Encapsulation, Polymorphism, and Inheritance.
VB 6.0 had Encapsulation and Polymorphism but no Inheritance.
It probably didn't make sense for Microsoft to just update VB 6.0 as it was also competing with newer and better languages at that time (like Java) that has full OOP capabilities and thus the "dot Net" was born.
Since this was written from scratch, the VB.Net version is fully OOP but migrating from VB 6.0 to VB.Net was not that simple and easy. You can't just load the VB 6.0 codes into a VB.Net environment and make it run. The reason was simple: It was not intended to be like that --- and later Microsoft announced that it will no longer support the VB 6.0 language.
So it was simply: keep your existing VB 6.0 and just write your new systems in VB.Net; and this is still the case even as of this writing.
Most systems written in VB 6.0 are so huge that they can't just rewrite something from scratch and be confident it would perform the same as the existing ones. This would require years of development and with that, huge cost to companies just to migrate VB 6.0 applications to VB.Net (probably 40% in development and 60% in parallel and stress testings).
So what's COM? It stands for Component Object Model --- an old technology from Microsoft where it allows programmers to basically create components that can be re-used by other objects and even allows programmers to use Windows components.
For example, if you've created a function that converts temperatures from degC to degF then you can put it inside an ActiveX "DLL (Dynamic Link Library/ies) and be used my many applications. Unfortunately, this is also the time when "DLL hell" was born --- it's basically an issue where a shared library is used my many applications but using different versions.
This issue has been addressed in the NET framework.
So to summarize, it was essential for Microsoft to leave the COM and migrate to NET in order to address some of the issues (at least) with Visual Basic. The other reason was for Microsoft to be able to compete with newer technologies that COM simply cannot do. For programmers, this move gave us tons of tools that we'd normally write in VB 6.0 but is now readily available in dot Net. The dotNet IDE (Integrated Development Environment) was also a huge time saver for programmers and if you've used both VB 6.0 and Vb.Net IDEs, you'd know what I'm talking about.
Is VB 6.0 still relevant? Of course. As long as there are systems out there running VB 6.0 then it sill makes sense to know VB 6.0 but schools should be teaching VB.Net because that's the better path to a programming career compared to VB 6.0.
Most people see VB 6.0 as bad and VB.Net as good, but I see them as "tools". Use VB 6.0 skills when supporting legacy applications or when the system you'd be deploying to does not or cannot install the dotNet framework. Use VB.Net for all other requirements as much as possible.