Visual Basic Turns 25
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
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."
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.
[0] https://news.ycombinator.com/item?id=11756195
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).
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.
It's really sad, because the tech there was really impressive.
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.
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.
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.
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 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.
(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.
Using Cn as new SqlConnection()
End Using
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.
(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.
(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:
Dim V() As String, W() As String
ReDim V(10)
W = V
ReDim V(20)
MsgBox UBound(W)
(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))LoadLibrary load the DLL, then GetProcAddress to find the function, then call it.
We converted some of these to VB.Net and then had to jump through a bunch of hoops (reg-free COM) to use it in that way.
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.
[1] Bruce McKinney, Hard Core Visual Basic http://vb.mvps.org/hardweb/mckinney.htm
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.
But nowadays everyone wants to make all GUI's everywhere web-based, it seems like. Which is okay, but much more to learn.
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.
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...)
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.
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.
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.
The $2k prototype/hack has a way of becoming a business-critical thing when you're not watching.
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.
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.
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)
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?
> abject lack of maintainability
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.
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 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.
VB.net is (modulo a few unimportant exceptions) just C# transpiled to a more annoying syntax.
I also wrote a bit, for example:
http://www.amazon.com/Visual-Basic-How--Definitive-Problem/d...
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 :)
True, and that was good. But it became bad when businesses made that "stuff" part of business-critical processes.
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.
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)
Further, at a time when they are open-sourcing so much they still keep vb6 closed source so that no-one else can either.
It's almost sadistic.
VB.NET was always meant to be the path forward, and VB.NET, at least, is open source now.
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.
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.
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.
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.
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.
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 actually got me into Windows development - coming from C & DOS, at the time the message pump was difficult for me to grasp.
For LOB apps, VB1-6 was the most productive language by far.
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.
Though powershell shows promise it doesn't run inside the Excel runtime and its a pain convincing others to use it.
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.
It wasn't perfect but you could make really useful apps really fast and (relatively speaking) they didn't look like shit.
I guess I should say it was the Rails + Bootstrap of its day.
I got a ton done with VB. It was a nice start to my career. I'm grateful for it.
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.
This in that you first placed the button, and then wrote the code "inside" that button.
Most dev tools seems to treat the UI thing as something you do in a parallel track to the code, or create via code.
That feature alone was the reason for its strength. And its danger.
Why are they celebrating its birthday?
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!
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.