Despite much of the hate VB has gotten over the years, it served an insanely important purpose in the rise of internal business software. When I was at MSFT, me and the PM who owned the compilers for VB.NET and C# did a usergroup tour through Florida and I was amazed at how much of their world still runs on VB6 applications. Something like 1/3 of insurance software still does. It was one of the biggest reasons that Microsoft had to keep extending support for XP.
The transition from VB6 to VB.NET was a really sad one as it lost a lot of people - .net is a lot more difficult than 6 was. The result is that an entire group of people simply stopped making software and now we have businesses running on applications that are more than 20 years old that some random person in the company threw together over a week. There's a huge gulf between building a VB6 app and throwing together a web app today and despite much of the progress that has been made, we've taken some big steps back in terms of accessibility.
The difference between VB.NET and C# is pretty superficial, but I sincerely hope that someday people can experience the magic that something like VB6 offered. A lot of people got their start in programming thanks to it (myself included) and it's sad that it fell by the wayside to make way for "real programming."
I work in industrial automation, and you really don't want to know what an awesome impact VB6 had on manufacturing. As `sjm-lbm noted below [0], it fills that essential niche between stuff that's useful and stuff that's too important to kludge. And I think as programmers/engineers, we should all kinda grok that you can get away with a lot of kludge before the world ends.
My favorite take on this idea is a guy in a forum replying about how vilified VBA is. I can't find the note for the life of me, but basically he said "You may work out and find the perfect tool for the job, but sometimes you just need a turbo-powered pneumatic nail gun to bang out something that mostly works." Skilled carpentry is a thing of beauty, but sometimes you just want the goddam floorboard held in place so the painter can get to work.
PS: I've perpetrated my own intellectual violence upon the world via VB, and generally it's what got me programming in my job. I learned C in high school, did some C++ in college, but I really got started in VB6. Eventually I escaped to Python, but man, I still appreciate how ubiquitous VB is. In Windows land, you can always fail back to some absurd version of VB (either in some VBA in a remnant Office installation, or VBscript, or the like - they're all a bit different, but not enough to stop an enterprising hacker).
Microsoft actually did release a good tool for the non-professional segment for writing database apps called lightswitch, that was better, higher level than VB. But they stopped selling it after some time. Shame.
It's actually a general problem in the market for software development tools, somehow the market for them isn't functioning well, and some great tools that we know how to build aren't produced.
Lightswitch was an amazing example of poor positioning. If you looked at the marketing material for it, it was positioned as a tool to "build three tier web applications" followed by a bunch of words that I didn't really understand.
It's really sad, because the tech there was really impressive.
Lightswitch was also tightly coupled with Silverlight when first released. The death of Silverlight doomed it. I believe that there is an HTML output version, but I doubt there is much interest.
For a very brief period of time it was actually a standalone product that was being developed when I was at MSFT (2010ish), but eventually they just rolled it into VS.
I taught myself to program at a professional level working on VB.NET. nothing i'd ever tried "clicked" with me until i could see all the pieces coming together. The syntax reminded me of old VBA macros I'd built, and there was a great online support community. (Stack Overflow is an incredible resource). I still work in VB.NET but i also use C#, R, and a bit of Python.
And of course, my VB.NET usage was all industrial test automation, it's the closest language to the VBA/VB6 that all the engineers were familiar with, easiest way for them to get comfortable with our solution.
Yup. You've heard of defense in layers? Well, VB is a leaky sieve that you can try from different angles as each layer fails.
So... you didn't hear this from me. This certainly was from some other engineer tasked with getting $THING done in a corporate environment where everything was locked down and noone had admin. (Never mind that anything on the floor had to have the password taped under the keyboard - or to save time, monitor.) I mean, someone had admin, but it wasn't really obvious who in the plant did and the ones who supposedly did had bad privileges set.
So you try to do something absurd like copy a log file automatically in the event of a line crash to a network store. But you can't run the nice application that shadow copies without admin. So you try a batch file, but no dice. Then you try VBA via Excel, and that sorta works, but now you've got to keep Excel running as a monitor, and that garfs up occasionally when the operator alt-tab-resets-power-to-everything. So you try a VBscript, and find that you can plonk that down in the Windows Startup folder and it sorta just works and thank god that's not an issue anymore we can just get back to fixing the line.
Every time it fails you can try again from a slightly different vantage point, retreating further as it fails, perhaps appropriately, you need to spend a day on the phone with tech support and get the damn thing done right.
Agreed. My start as a professional developer was an internal tracking tool that started as an Excel spreadsheet, which I turned into an Access database... added numerous VBA macros... once I'd hit that limit I created an entire frontend in VB.NET, which led me to C#...
I've left it all long behind now, but those were some great building blocks. It was around a decade ago, and when I left the company they had announced plans to replace everything (my code included) with SAP. Last time I spoke to someone there (about three years ago) that plan has still not been completed.
My first real desktop application written in VB .Net has been used once a month for 6 years, and is still going strong, even after I've left the company.
Like a dead relative, when I think of VB6 I look back fondly on being able to edit live code at a breakpoint without having to restart the debugger, and ignore the traumas like the interface to the win32 API and the half-baked error handling.
What is "real programming" anyways? What separates VB6 from the "real programming" languages? Try to answer this question not from the perspective of an opinionated programmer, but in the general framework of "what it takes to make a working product using VB6 versus other things out there"?
VB6 is basically as simple as a form builder to start with. You start with designing forms for every screen you need and then write logic for specific events, like a button click event etc. It was much more simpler than say a modern framework based on MVC.
VB6 would spit out an exe that could often be installed by just copying it to the client machine.
You could also generate DLLs that other applications could easily load and use. These days you can still do it, but it's much more complicated (i.e. registration-free COM).
I'm pretty sure that Windows Forms in C# is still pretty lenient in this regard. It'll give you an .exe file that, if you only reference a single project in your solution, you can copy directly onto a target machine and run. If you're referencing multiple projects, it'll compile DLLs from them and you'll need to copy over those as well.
I love Windows Forms for prototyping stuff for this reason. There's much less overhead and GUI prototyping is super fast. It falls apart if you have a complex application that needs to be maintained over time by multiple people, but it's great for just getting some simple task done. I think the current generation of web programmers miss out on some really useful tools by always thinking in terms of client/server. It's not always that you want or need a webapp to solve your problem.
VB.net introduces a few rough edges, everything is class based, you have namespaces, lambdas, etc. But honestly the step from VB6 to VB.net is a pretty modest step, and when you have tasted generics, linq and its collection extensions functions (OrderBy, First, Last, Max, etc), a consistent collection indexing (VB6 switches between 0 based and 1 based), got rid of that useless "set" keyword, made all function parameters byval by default, which avoids having to write byval before every parameter, used lambdas (there are quite many problems where it is just nice to give a callback as a parameter), type inference, initializing a variable on the same line it is declared, multi-threading, etc, you won't go back to VB6.
I fully accept the non backward compatibility of the code argument. If it's a big project, and it's working, and it's in VB6, I can understand not upgrading it. But in term of functionality VB6 is way behind modern VB.Net.
The step from VB6 to VB.NET is far from “modest”. There are many fundamental differences between the two. For the most part VB.NET is a strict improvement over VB6, but there are a few things VB6 does better than VB.NET:
(0) Reference counting: VB6 cleans up arbitrary resources (not just memory) in a deterministic fashion. Think RAII, minus the dangling references and associated gotchas. In business application programming, not worrying whether you closed database connections in the right places is a major productivity boost.
(1) Programmer-defined lower and upper array bounds. You iterate an array's index range with `For idx = LBound(arr) To UBound(arr)`. It's as clear as it gets.
(2) Dyamically resizable arrays. VB6's `ReDim` doesn't give you a new array object - it really changes the size of the existing one. By contrast, VB.NET's `ReDim` is just sugar for replacing a fixed-size array with another, which is why it can only be used locally inside a method. The officially sactioned solution is to use `List`s, but `List`s can't be multidimensional.
Will release the connection as soon as you get out of the using. Actually better than that, ADO.net will keep the connection alive for a few seconds such that if you make another connection to the same server, it reuses connections. I think VB.net still uses reference counting. But it does full garbage collections in addition to that.
(1) The syntax has changed but does the same thing: For Idx = arr.GetLowerBound(0) To arr.GetUpperBound(0).
(2) I don't think VB6's redim preserves the array. It resets it to its default values. You have to use "ReDim Preserve" instead, which has the same behavior in VB6 and VB.net. And I think I remember that either way you can only Redim the last dimension of the array.
I think list feels more natural, I don't see a lot of value in writing explicitly the redim part of the code. I'd rather my code to focus on what I am trying to achieve, not some low level plumbing.
(0) The problem with `Using` is that you can forget to use it. Or you can use it with the wrong object. It's no better than `free()` in C. On the other hand, you when you program in VB6, you can't forget to reference-count your objects, because the language implementation does it for you.
(1) Noted.
(2) I know the difference between `ReDim` and `ReDim Preserve`. And I'm not talking about the array's contents, I'm talking about the array's object identity. In VB6, both `ReDim` and `ReDim Preserve` preserve the array's identity in spite of the size change. .NET arrays don't support resizing at all, so VB.NET hides the limitation by only allowing `ReDim` on local array variables, and implementing it internally in terms of swapping array objects.
And `List` stops being natural when you want it to be multidimensional.
(0) you can forget to call "Dispose" but the benefit of using "using" is that Dispose will get called whichever way you get out of the scope. Using "using" for disposable types ends up being some reflex and it would seem odd to me to see new SqlConnection without a using.
(2) I am not sure I agree with that either. The following in VB6 returns 10, i.e. the second redim has created a new instance of an array:
(0) You can't forget to call “Dispose” if you need objects to be cleaned up in a specific order.
(2) Try this:
Dim V() As Long, W() As Long, i As Long
ReDim V(1 To 10)
For i = LBound(V) To UBound(V)
V(i) = i
Next i
W = V
For i = LBound(W) To UBound(W)
W(i) = 2 * i
Next i
Call MsgBox(V(5))
Call MsgBox(W(5))
I guess it depends what you want to consume your DLL from. A .net DLL can be consumed by a .net application without any form of registration, and I would assume this would be the typical use case. It's only if you want to expose your DLL with a COM interface to be used by other languages that you need a COM registration.
You can do this in Windows Forms. You can (or could) drag a DB connection onto a form, hook it up to a grid, and have a CRUD app out in minutes. You could even do that in ASP.NET Webforms. But for cultural and technical reasons, it is frowned upon, even when wholly appropriate.
The biggest knock against VB6 being a "real programming" language has much to do with its pedigree as a proprietary language largely meant for a proprietary platform evolved from earlier language designs meant for 8-bit (GW-BASIC) and 16-bit (QuickBASIC/QBASIC) systems. There never was a committee to guide its development and set standards, and hardly any competing implementations to a standard for it. Furthermore, there's barely a community that can regularly voice their concerns and desires (beyond whatever forum Microsoft may provide) in regards to its evolution.
The various warts of VB6 (such as ON ERROR GOTO, lack of function pointers, GOSUB/RETURN, lack of equivalents to the +=, && and || operators of C, etc.) weren't beyond repair (after all, VB.NET is a great language taken on its own merits, with a few warts intentionally retained), but the true owner of Visual Basic apparently wanted to do a dramatic reboot of things and otherwise retire VB6. And it could and did so quite easily, there being no standards committee to answer to, and no community to negotiate with.
Don't get me wrong, VB6 is real enough in that people were able to do a lot of cool and useful things with it, and even took it levels way beyond the originally intended by Microsoft. So yeah it's a real programming language. Just not "real" enough for some.
And, for me, using Bruce McKinney's stuff[1] really helped fill the gaps. One of the things he said that really stuck with me was "Visual Basic makes 95% of the work really easy and 5% of the work impossible" (probably paraphrasing a bit). And then he'd go on to show you how to make a DLL in C++ that took care of the 5% and link it to your VB program. I stopped free lancing and making money off of VB somewhere between 5 and 6 so I wasn't really there for the whole transition to .Net. But before I found GNU and Linux I had a lot of fun with VB 4 and 5 and even managed to make a decent living from it for a while.
I did a lot of programming in Classic Visual BASIC and VB 6.0 was my favorite version of it. I was disapointed with the changes made in VB.Net because I had co-workers that didn't know how to program and VB 6.0 was easier for them to learn and be trained by me to use.
If you want to convert some VB 6.0 code to another language consider Jabaco:
http://www.jabaco.org/
It will compile to a JAR file and it is based on VB 6.0 syntax. People asked Microsoft to open source VB 6.0 but Jabaco is as close as you can get to that without being sued by Microsoft.
I'd kill to be able to use a form designer like VB6's, with a better language, like Haskell or Python. Present-day Visual Studio's form designer isn't good enough.
I'd love a python-backed form designer. I've been wanting one for ages. I've experimented with making GUI's with wxPython before but it's pretty clunky. I would have loved a good form designer to help accelerate it and take care of the basics.
But nowadays everyone wants to make all GUI's everywhere web-based, it seems like. Which is okay, but much more to learn.
VB was to the desktop what PHP was for the web. An accessible and easy to learn platform that got a lot of people into building shit quickly. Hopefully most moved on since.
I only used VB5 in the late 90s, but yes, absolutely.
When I was doing GUI stuff in Java (Netbeans and eclipse) in the mid 2000s... yes, all the OO stuff was better but boy did I miss that interface designer that just worked.
I remember a byte magazine article (maybe it was even on the cover) around the time of VB3 about how OO had failed in terms of what it had promised: re-use, productivity etc. But VB had more than succeeded on these fronts. Millions of programme were re-using these black box components. Not just the Microsoft ones. There was a big third party market as well. But it wasn't as sexy as OO. I think the article was wise enough to point out that it was OO but better than most implementations because of what it left out.
Vb6 was before my time, but I think autohotkey has filled the vacuum pretty well. There are a bunch of alternatives still around, like autoit, quick macros...
In the '90s, we were all supposed to look forward to a "marketplace of pre-built objects," which could be bolted together to build applications. That didn't materialize, because (as I understood it) of the industry's failure to standardize compiler output so that object libraries written in C++ could be binarily compatible with other software (someone can elaborate on this if they have more details).
But there was one exception: VBXs. We did indeed write a lot of software for some very high-profile clients using drag-&-drop VBX controls, especially things like data grids. VBXs did largely deliver on the promises we all heard at the time.
The other big hype at the time was how the newly unified UNIX camps were going to wrest the desktop from Microsoft. We all know how that turned out (except the people who are still saying the same about Linux...)
I am a huge fan of the Microsoft ecosystem, and I spent a great many hours developing VB.NET code at the beginning of my career.
VB6 is a scourge. The fact that Joe in HR threw together an application in a weekend in a testament not to its accessibility but to its abject lack of maintainability.
I think the important part here is that (in your example), Joe in HR wrote an application that is important enough to be used but not important enough to be professionally rewritten in a "better" language. I don't really think that speaks to faults in VB6, but to a sizable and interesting market for a product that allows non-programmers to write simple programs.
I have known people writing apps in MS-Office like Access, Word, or Excel using VBA, and I was assigned to convert it to VB 6.0 and SQL Server.
Usually the over the weekend projects need debugging and error trapping and other things to it. I can't tell you how many Invalid Use of Null errors where avoided by using the trim function and adding a blank quote "" next to the variable that held data:
result = trim("" & RS(index))
Just a simple modification that new programmers didn't know.
You remind me of programmers who will bill a client $50k for a $2k problem under the guise of it being done "properly"...oh, and keeping it a secret that an "improper" $2k implementation was an option.
People heap scorn on auto mechanics (for example) that pad bills, but many people whose work doesn't get their hands dirty seem to think they are subject to a different moral code.
> many people whose work doesn't get their hands dirty seem to think they are subject to a different moral code
Let's not try to turn this into some "workers unite!" nonsense. I don't think how dirty someone's hands get have anything to do with what we're talking about.
Using your extreme example, the the $2k option is wrapping half a roll of duct tape around a leak. The $50k option is buying warrantied parts directly from the factory (not OEM).
What both you and the parent ignore is that there's usually a perfectly valid $20k option (OEM) that is a fair middle ground.
> Using your extreme example, the the $2k option is wrapping half a roll of duct tape around a leak. The $50k option is buying warrantied parts directly from the factory (not OEM).
You haven't seen some of the things I have. There are some extremely dishonest people in this industry that would literally be in prison if they pulled financially comparable stunts in an industry that isn't so opaque.
He reminds me of an entire team of programmers who turned up their noses at VB, insisting that they work in VC instead. When, predictably, the VB prototype of the product worked perfectly well (the whole app was database-driven)... they were all fired and the product was finished by one designer and a team of contractors instead.
I think there is much to be said about Jack in IT who spent 6 months working on a program that doesn't even meet the business' needs in the end, for something Joe could have done over a week end.
I mean, yeah, unmaintainable code sucks. But I think this highlights the need for more accessible coding. The web became huge because it was so accessible. Yes, it generated a lot of crap code, but if 10% of projects add value to society, the more projects, the more valuable projects.
> The fact that Joe in HR threw together an application in a weekend in a testament not to its accessibility but to its abject lack of maintainability.
I don't see how "easy/fast to create" necessitates lack of maintainability, nor that it is a statement AGAINST accessibility. (without regard to the quality of VB6)
Sir, you jest. However I have indeed seen Joe in HR throw stuff together in a weekend, and it worked, mainly because Joe knew his business intimately and Googleing VBA was easier than writing a business requirement.
Yes and it does the job. If it's unmaintainable as alleged then that's a refactoring job which is a lot easier imo than starting from scratch.
Joe from HR has given him his UI and undeniably laid out everything the code needs to do.
Mr Real Programmer should just then get on, stick in his tests, refactor and quit whining about Joe's code.
After all what's he there for, did he expect Joe to do everything?
You seem to think that I'm making some sort of judgment against Joe, or that I think I'm better, or something of that sort. I didn't say or imply anything like that.
I first learned to program in VB6 when I was 14 in a high school class. I remember being so excited by programming that I flipped to the back of the book and trying to implement the advanced programming problems only a few weeks in. An explanation of Conway's Game of Life caught my eye, and I tried to implement it. Unfortunately, I hadn't yet learned about arrays or loops, so my implementation was just thousands of lines of if statements. It took me hours of copying-pasting and modifying just to get a 5x5 board working, and I remember balking when the book suggested trying to make a 50x50 or 100x100 board. It was at that point I realized all the content in the middle of the textbook might be worth looking at after all!
In a few more days I'll be 26. I started programming with Visual Basic 6, since then I have moved on. From time to time though, I can't help but try it out again now and then. I've seen many programmers start out with it and move on through the field into other languages. Many interesting projects have been made in Visual Basic 6 alone. Everything from private server software, to game cheating tools (packet injections), online rpg game engines, and so on and so forth (and throw in malware in there somewhere too). I am grateful for Visual Basic despite having moved from it, I know many despised it, and some of that group once coded in it, but I have to appreciate my roots despite the good or the bad I still learned programming through VB6. Thank you to whoever has ever worked on Visual Basic 6. Happy belated birthday as well.
I'm 5 years older. I started in Qbasic and moved to VB4 or 5 pretty soon after that. I've left them behind, but I've got a similar feeling about those languages.
These days, I guess I'd do some TK thing in Python if I was going for speed of development, but that seems a few steps backwards from what I could do (almost) 20 years, in a few ways.
Would be nice. Sadly node.js shares many of VB's warts, whilst having few of its nicer features.
I'm not the only one who looks at what the industry had in the 1990's and thinks we've gone backwards. All Microsoft had to do was build a non-crappy online update and installation system, and our whole industry could look very different. But MS failed, utterly, in fact they made it worse, and we've ended up with the web - a pale imitation of real software development, but hey, you can deploy it without being hamstrung by a dysfunctional IT department and stuff updates silently.
I'm uncertain saying Node.js is the VB of the 2010's is a nice thing to say or not.
I wrote tons of VB code but, in retrospect, I realize it was a crude tool. Efficient, in that it allowed me to build some fairly large business apps, but not really something that encouraged best practices of later eras.
In 1996 a friend demonstrated to me how to write an calculator in VB 4.0, I was immediately hooked. it opened the GUI world to me. at that time I couldn't read English and all I could was trial-and-error. Couple of weeks later, I coded a traffic simulation and show off to another friend who studied chemistry. Guess what, the guy learnt programming and became CTO of a Chinese internet giant.
I've actually learned programming when I was 12 with Visual Basic! I had a little book called "programming for kids" and it had a trial version of VB6 attached to it(it was fully functional, except that it couldn't export exes). The book had chapters on how to make a calculator, a simple notepad with save/open functionality and then at the end a gem - pong game made in VB. It was amazing. Now I work as a professional game programmer in C++, but I always think fondly of VB.
I quit programming VB 12 years ago after using it for two years. I still vividly remember its syntax, patterns, forms, adodb/dao stuff. It's as if I never stopped coding in it. I've been into many languages since, ending lately with Golang. Nothing felt so easy and accessible as VB. Happy 25th birthday, dear Visual Basic.
Thanks for the kind reminder. At the same time when the VB was a popular tool, I looked for similar platforms on Linux. Gambas provided very familiar, if not identical syntax, however its Forms editor wasn't as nearly as powerful as VB's. Anyway, I'm glad to hear that Gambas is still around, will certainly play with it.
Actually VB is dead. VB.net isn't VB any more than JavaScript is Java, and we shouldn't let Microsoft's marketing team pull the wool over our eyes by pretending there's continuity between the two.
VB.net is (modulo a few unimportant exceptions) just C# transpiled to a more annoying syntax.
The original Visual Basic was revolutionary. As a long time c programmer, at the time, I saw the custom control market opportunity and jumped in as co-founder of Mabry Software. Life was good, until vb.net.
Nowadays it's almost a meme to hate on VB, but I wrote my first desktop application with VB6 when I was in high school, circa 2000.
I knew Basic and a bit of Pascal, but the GUI builder of VB captivated me. It was so easy to create things with it! I quickly embraced it and developed many applications, among which a Scalextric car controller (attached to the voltage of a real car) and a math tutor for kids which got me a grant on my first year of college. It was pretty crappy but I still hold VB6 in my heart :)
Its interesting how much hatred there is for visual basic these days. I understand, its the bane of my existence right now replacing thousands of things written with it. But I never stop being amazed at how successful it was. People who had no business programming were able to get stuff done with it. Imagine if MS didn't corner itself and ultimately kill the language by implementing only for windows?
This was often an argument I read in my Systems Analysis textbooks back in that era: "Bob from Accounting threw together this app, now we need to replace it with a staged CMMI-compliant development process that does things properly". IRL: it resulted in an expensive and late waterfall project that Bob, and the rest of his department hate.
I'm sure that the code quality was atrocious, but in many ways, it is the ultimate Agile goal: Bob is solving his own problems, cutting through red tape, and addressing real business needs. It's a pity that the idea was abandoned, instead of finding ways to reduce the ways Bob could shoot himself in the foot.
I've seen that too (I imagine we work at the same place) and always wondered why it wasn't licensed to our organization. I know nothing about Windows architecture, but I'm always impressed with the backwards compatibility. The VB6 runtime is supported through Windows 10! And, although not officially supported, the VB6 IDE still installs and runs fine.
There is a migration, though slow, from VB6 to ASP.NET C# stuff.
We use VB6 because of the component-like nature of how it can integrate with other parts of a larger application--and it usually doesn't have catastrophic failure (like a segfault) which can be contained. Another aspect of why it is used is because of the low-memory requirements, which by extension means one server can host more application sessions for more users. (It is easier to upgrade one server's software instance than thousands of individual workstations)
Microsoft produced several migration tools from VB6 to VB.NET over the years. An "Upgrade Wizard" to do a first pass conversion. Some integration tools to run VB6 COM components in VB.NET applications and vice versa (VB.NET code as VB6 ActiveX components).
VB.NET was always meant to be the path forward, and VB.NET, at least, is open source now.
The migration tool was next to useless. Even if, after a lot of effort, you migrated your app it would typically run a lot slower than on VB6.
The only practical way to "migrate" was a complete re-write, that way you could have something comparable in performance to the original app.
And that is why there are still so many VB6 applications around today, the cost of migrating (to an app that was no better than the original) was rarely justified.
Now that Microsoft support VB6 until at least 2025 while VB.Net is falling in popularity (only 12% of .Net developers use Vb.Net now) it looks like those staying with VB6 made the right decision.
«Now that Microsoft support VB6 until at least 2025»
Microsoft only supports the VB6 runtime. The VB6 IDE and editing tools are no longer supported. Building new projects or new builds of VB6 applications is dangerous and unsupported.
«VB.Net is falling in popularity (only 12% of .Net developers»
So what? C# and F# are both good languages, and it makes sense if VB.NET is a good stepping stone to one or the other. VB.NET isn't going anywhere, it's also a good language for those that want to use it.
«those staying with VB6 made the right decision»
Hah. I'm not sure I agree with "right" from your analysis. Those who have stuck with VB6 in spite of all that has happened in language design and platform changes since VB6 was discontinued have certainly decided to be their generation's COBOL programmers. Certainly there will be money to be made there in ridiculous contracting fees for companies that don't know any better, and that's a possible definition of "right decision", I suppose.
What are you talking about? In that very comment I just pointed to several ways that Microsoft (not even getting to third party options) tried to give a helping hand to people to migrate existing projects at the time of the VB6 to VB.NET conversion path. Yes, it wasn't an entirely smooth transition, but there was a forward transition path.
The assistance they provided got better as the years went by up to about the time of vb2008. Even then the assistance was such that migration of existing vb6 code was recommended by microsoft as the option of last resort. By the release of vb2010 microsoft appeared to have given up on migration completely and removed the upgrade tool from the product.
Too little too late is probably a fair description of it.
Yes, but "a bumpy road is still a road". Forward does not imply "painless", and Microsoft did try to help, even if it felt like "too little too late". VB.NET was still the forward path from VB, whether developers and companies liked that or not.
I have some sympathy for Microsoft on this. Some of the changes could have been backward compatible (like making "set" optional). But some breaking changes had to be made. Like making all function parameters byval by default. Having everything byref by default in VB6 was just a bad initial design.
Not sure I understand your second example.
The upgrade code to VB7 could just have inserted a ByRef for every parameter lacking both a Byval and a Byref?
VB6 was amazing as a first language. When I learned to code for the first time I was an impatient kid and I just wanted to see my programs compile and run on a nice GUI, vb6 gave me that and I wish it was still around for my younger brother to learn how to code with it.
I have a lot of fond memories of VB6, as I started using it for an internship in college, when then I got hired full-time after graduation to keep up the app, as the sole developer/IT professional at the company. VB6 had its flaws, certainly, but as a 21 year old kid figuring out how to architect a software system, get projects done, and get the system working on the existing Novell Netware infrastructure, I didn't need to fight with C++ or deal with the vagaries of Delphi. VB6 was a great tool, VB.NET became a different tool, and I wish for the sake of not-really-programmers everywhere, VB7 had existed.
I find it quite interesting that 90% of the comments here associate VB to VB6. It's a bit like if 90% of the comments on the anniversary of python would be about python 2 and how people missed it (or not)...
This is because a huge community of VB developers built up during the VB1-VB6 era, and then Microsoft blew that community to smithereens with the language and licensing changes that accompanied the move to .NET. VB still exists in the form of VB.NET, but in terms of popularity it never recovered from the diaspora of VB6 users who abandoned the platform and never looked back.
So today you have two groups with an interest in talking about VB: a huge community of VB expats who moved on to other languages when the crack-up came, and a relatively tiny community of VB.NET users who either stuck with the platform or came to it later on.
They stopped selling licenses for Visual Basic 6 through most channels when VB.NET launched in 2002. Not "warned that they were going to stop selling licenses," just... stopped.
So you had all these companies who had built up enormous codebases in older versions of VB, the last of which had been released only four years earlier, who suddenly couldn't buy the software all that code depended on anymore. Many of which were huge enterprises that were used to being able to phase out old software extremely slowly; so having the plug pulled on "classic" VB so abruptly was kind of terrifying for them.
Microsoft's official response to these customers was "VB.NET is much better, just use that." But you couldn't take a VB6 code base and run it under VB.NET without at least some modification to bring it in line with the new syntax. And VB.NET felt less like a version of VB than like C# with a coat of VB-colored paint on it, so the developers who would have to make those modifications faced the prospect of having to learn what was more or less a whole new language in a big hurry.
Since demand for client-server software (which is what you used VB to write) was in decline by then anyway, and apps that ran on the Web were the New Hotness, lots of VB developers decided that if they were going to have to learn a new language it may as well be one that let you deploy to the Web. So they didn't bother with VB.NET and moved to platforms like C#, ASP.NET, PHP, Python, Ruby, etc. instead, all of which had a better story for developing Web applications than VB.NET did. (Disclosure: I was one of these.)
Of those developers that didn't flee, most simply did the easy thing, which was to refuse to do anything; they just hung on to their existing VB6 licenses and kept on churning out VB6 code like nothing had changed. All that old VB6 code meant that you could actually make a good living for a surprisingly long time this way, just tending old legacy apps and keeping them running as well as possible.
It has kept some of its niceties. It's one of the rare case insensitive languages (less pointless bugs as a result of typos), it is very expressive (I just don't get the love of certain programmers for special characters), and it provides a natural evolution for business people into programming, many of who even today have learned the basics of coding with VBA (like me...).
And there aren't that many breaking changes between VB6 and VB.net. Enough to make a VB6 program not compile. But not enough to really stand in a way of a VB6 programmer upgrading his skills over a couple of weeks.
> And there aren't that many breaking changes between VB6 and VB.net.
If you just count syntax, maybe. But the entire environment and API of VB6 wasn't there, making the transition pointless. It's like arguing that Windows C programmers have an easy transition to C on Linux because it's the same language.
VB.Net in it's current form should never have existed. VB.Net should have been able to run VB6 applications unmodified giving a straight forward transition from VB/VBA to .Net. Instead most apps were never ported from VB6 and VBA. It was a huge missed opportunity.
Like I said: lexical syntax. Case sensitivity and whether you use "End" or "}" are, to me, down somewhere around tabs vs. spaces in terms of what matters for the usability of a programming language.
Agreed. Also, given the current cultural fork, I do think there will be plenty of loud, vocal people out there commenting on how Python 2 was the last "real" Python. Programmers are weird.
I actually associate VB 'being awful' with VB4. In version 5 you could finally compile to EXE, so things ran faster and you didn't have to include the runtime DLL. It was finally a 'real' language to a lot of us on AOL at the time. I was more interested in writing Doom/Quake related stuff in Visual C++, but I played around with and got a lot done with Visual Basic 4.0 and 5.0
All the PC tech support calls from the past, all because VBRUN300.DLL or VBRUN400.DLL didn't exist, or were the wrong version...
VB 1.0 was a revolution, really. I went on to buy Delphi and Paradox. Delphi was really something but the nod has to go to VB for the massive leap it took.
It's not just 25 years for VB, it's 25yrs for all those GUI developers who grew up starting with VB. Now we're on Qt, JavaFX and React but as I write this I can't help but think - VB is more productive than React ;-)
I had the most amazing experience learning how to program in VB6. It is, to this day, still the most amazing experience of creating desktop applications I ever had. Partially because I had a really awesome high school professor at that time, but still...
In my final year of high school, I decided on my own to try using the latest .NET version of Visual Basic for my graduation project. It wasn't hard, it was just a little bit more complicated and a bit disappointing experience when compared to VB6. My project was working, but not perfectly. I felt like I could ace it in VB6, but it felt way too outdated to be usable in the long run (turns out I was right, Microsoft killed XP, my high school switched to Office 365 and Windows 7, therefore, my VB6 project would be unusable now by the school administration).
I still feel the nostalgia whenever I think about how easy was to program in that thing.
I work at an investment bank and I have daily contact with VB. It's awful and I wish it had some modern features like try catch blocks, but to automate simple tasks in Excel or Outlook it seems to be the only option.
Though powershell shows promise it doesn't run inside the Excel runtime and its a pain convincing others to use it.
I started work at the tail-end of the VB6 (legacy systems were maintained with VB6, new work was done in .NET). We lost a lot of good people in the transition.
Unfortunately, many modern developers (including me) avoid VB, in all its incarnations, and there is a fair amount of technical snobbery in the dev world (there always was-even in the VB6 world). The RAD tools currently on the market demo well, but don't seem to lend themselves to more complex use-cases. In the absence of good evidence to the contrary, draggy-droppy RAD is looked down upon, in favor of markup based approaches, and inappropriate complexity is worn as a badge of honor (gross generalization, but I think valid for a substantial chunk of the business development world).
An Agile development process, coupled with a solid RAD platform should yield interesting results.
I did a few programs in VB in the early 90's. It was pretty easy to buy components and get data out of our database. It was also quite nice for writing a program that generated lesson plans from a score on the LAP / E-LAP assessments.
I admit I was amazed at the ability to buy VBX components to do so many amazing things. It was really easy to plug them into your programs and get stuff running.
I did cheat a bit and use a module that made the GUI of the programs I wrote look like the NeXTSTEP screen I was using at the time.
While HTML was the first kind of code I ever wrote, I never felt like I was doing much more than I was when I typed up something in Microsoft Works. It wasn't until I used VB when I was 13 or 14 that it hit me that I could actually make computers do what I wanted.
VB6 was magic during those days. VB6 played a great role in making computers useful to small businesses and widespread adoption of computers. It also reduced the cost of software development.
A lot of the people have moved on from vb and also as vb6 applications have continued to work in every release of windows there is less panic about having to upgrade.
However, I have heard that windows 10 is not proving quite as trouble-free as 7 and 8 were.
I honestly wished they would of somehow open sourced Visual Basic 6, it was quite interesting being able to create software rapidly and easily that couldn't be "decompiled" the way .NET / Java applications can be reversed back from bytecode. Unlike Delphi / Pascal which are a bit harder to just pick up and learn by comparison (try just giving a child Delphi, and then give them VB6 and see which one they could work quicker in). I think VB.NET had not much of a point with a language like C# around. Maybe they should of redone some parts of Visual Basic .NET to make it more adaptable by all programmers. Multi-line comments is one thing I wished it had.
There is Gambas, which while not a clone in the way FreeBASIC is of QuickBASIC, is at least intended to provide a similar experience. https://en.wikipedia.org/wiki/Gambas
To Microsoft, VB.NET is still Visual Basic. They didn't kill VB, they made a new version that was different. The VB.NET compiler version numbers even start from 7 as it was/is considered the successor.
Because it brings out the nostalgia for people. Also a way to signal how long you've been programming, or that you stared programming early on in life.
Pressing ALT-F11 in Office 2016 is quite depressing. They haven't spent even a minute improving anything in 15 years. It's quite shocking for a functionality which is so critical to so many people and companies.
And microsoft is pushing for people to use javascript instead.
If you think that VBA code written by novice programmers looks bad, I think you should look at javascript written by novice programmers. A guy was trying to draw a line and decided to do it pixel by pixel by adding "div" of 1px by 1px to the DOM, and each pixel was added with a callback!
I look back on Visual Basic with a mixture of trepidation and fondness. If you were a programmer who had experience of building well structured applications in C++, Python etc. then you could get a lot of stuff done and built on Windows. If you inherited a bad application, however....it was really bad. You can't deny its importance to desktop applications though.
The switch to VB.Net was the first time that you couldn't simply take your existing code and recompile it in a new version and carry on adding new features. That's where VB.Net, and .Net in general, simply didn't take off. Most people found out they simply didn't need or even want the complexity of full object oriented development either.
What Microsoft should have done was built a rapid development environment on top of .Net, distinct from programming in C#, that allowed you to take classic VB code and simply recompile it. The switch to .Net has never really happened for Microsoft and if anyone has been rewriting applications they are as web applications or mobile apps - which Microsoft are not a part of. It will be seen as a pivotal moment where Microsoft simply lost developers. You see it now with pandering to bringing Bash to Windows, amongst other things. No one cares about Windows development.
The transition from VB6 to VB.NET was a really sad one as it lost a lot of people - .net is a lot more difficult than 6 was. The result is that an entire group of people simply stopped making software and now we have businesses running on applications that are more than 20 years old that some random person in the company threw together over a week. There's a huge gulf between building a VB6 app and throwing together a web app today and despite much of the progress that has been made, we've taken some big steps back in terms of accessibility.
The difference between VB.NET and C# is pretty superficial, but I sincerely hope that someday people can experience the magic that something like VB6 offered. A lot of people got their start in programming thanks to it (myself included) and it's sad that it fell by the wayside to make way for "real programming."