Slashdot Mirror
Why Visual Basic 6 Still Thrives
theodp writes "Microsoft recently extended 'It Just Works' compatibility for Visual Basic 6 applications through the full lifetime of Windows 8, so VB6 apps will have at least 24 years of supported lifetime (VB6 shipped in '98). So why has VB6, 'the un-killable cockroach' in the Windows ecosystem, managed to thrive? 'Cockroaches are successful because they're simple,' explains David S. Platt. 'They do what they need to do for their ecological niche and no more. Visual Basic 6 did what its creators intended for its market niche: enable very rapid development of limited programs by programmers of lesser experience.' But when Microsoft proudly trotted out VB.NET, the 'full-fledged language' designed to turn VB6 'bus drivers' into 'fighter pilots,' they got a surprise. 'Almost all Visual Basic 6 programmers were content with what Visual Basic 6 did,' explains Platt. 'They were happy to be bus drivers: to leave the office at 5 p.m. (or 4:30 p.m. on a really nice day) instead of working until midnight; to play with their families on weekends instead of trudging back to the office; to sleep with their spouses instead of pulling another coding all-nighter and eating cold pizza for breakfast. They didn't lament the lack of operator overloading or polymorphism in Visual Basic 6, so they didn't say much.'"
I'm one of them. I still actively use it today. I know how to use it, and I never had any interest in learning .Net. I've got several mission-critical apps written in VB6, and I'm updating one of them right now. We have no plans to move to something else. If it ain't broke...
I don't respond to AC's.
A "just works" version of Windows, that MS sold support for, marketed toward businesses, that just stayed the same forever. As it is, MS makes its money on new versions. That's fine for MS, but bad for businesses that don't want to upgrade every four - six years. If MS made money selling a business copy of windows and then got a fair amount for support and updates on it perpetually, it would be win/win for businesses, developers, and MS.
Where I work at, we installed new systems in police stations in the last two years that were brand new and had Windows XP on them, because the software at the time didn't have Windows 7 drivers.
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
If you had VB5 and you got VB6 you could upgrade your app to a vb6 application very quickly and your program looked and worked just like it did before. .NET breaks all but the most basic application, and there is a lot of rework to be done. Often these VB6 apps are not the best design and, and you need to find a .NET compatible version of your third party tools, then they are probably quite different and you need to rework them again.
Upgrading you VB6 app into
Next you have the .NET framework. I write a program in visual studios 2010, Now I need to make decisions... Do I compile it for .net 2.0 and not have as many features but know that my system will work on most modern windows systems, or work on 4.5 and require all the users to upgrade their system? Why can't I just compile it into a static .EXE
Finally you have older developers. These guys are not Computer Scientists, They studied other fields and happened to learn computers, and started to program before a lot of the formalization in good form came into place. .NET seems unnecessarily restrictive to them. Why do you need to type all this extra crap. I need it to do this, why do I need System.Windows.Forms.PotatoGun.PopSound() instead of PlayPop Often these older developers are just maintaining the existing system that they have coded decades ago. So there is no real push to upgrade and give them a new project just because it needs to support .NET
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
There are many projects, usually internal or niche market applications, which have decades of legacy code to keep the product running. This is not a choice of the developers or done out of laziness, this is what their employers have given them to work with.
If you have to rewrite vast amounts of code because the programming language is out dated, you will find that depending on the size of the project, the company who owns the project will be on the hook for millions of dollars to rewrite it so that it will work with modern environment.
If you are a company in placed in this position of having to rewrite everything, what is there to say that you are going to stay on the Microsoft ecosystem. You have emerging technologies in the enterprise (iOS/iPad/Objective-C), you have Web Applications and "Cloud Computing" (Which are platform independent and would most likely run on a non-Microsoft backend) and if you are a developer who just wants to get it working on the cheap (Where the market is vertical enough that the customer will use any platform you tell them to because they need to run your app) you could probably save a tonne of development cash by just making it run on WINE on GNU/Linux
Better for Microsoft to keep supporting developers who have their ecosystem running on Windows, as these applications directly translate into sales of Windows licenses. If Windows did not have compatibility, then Windows will be just like the rest.
Incidentally, this is why Windows on ARM Tablets will ultimately fail, as there is no compatibility with x86 apps unless it is 100% written in .NET or HTML5 (not that many out there in the whole Windows ecosystem).
Because you can make a GUI using Visual Basic and see if you can track an IP address.
VB6 is simple, but there is a surprisingly large amount of power to be tapped from it, if you understand the underlying infrastructure.
Having done some hard core COM programming 10 years ago, for a Computer Based Testing "test driver", our team learned we could spend 2 days to get up a "ActiveDoc" in C++ using ATL, and WTL, or we could do the same thing in VB6 within an hour. Considering how fast it was to implement ActiveDocument and custom COM interfaces, I changed my mind on how weak I perceived VB6 was. (Unfortunately many of the VB trained, customer-based implementors of our interface were not as astute, and even in a VB6 environment didn't understand what they needed to do to create a component that would properly talk to the rest of our system.)
Still, knowing how quickly VB6 would let one get up an interface, I was able to help a room mate of mine create a level editor for our own rolled version of Zelda. It was a little cumbersome to learn how to read individual bytes of the palette based sprite files, but VB6 had all the power there.
All that said, VB6 should die IMHO. After (C# / VB).NET came out, it became a lot easier to make object dynamically talk to each other and perform byte level manipulation.
.NET thrive is because the Visual Studio IDE demands it, unless you are doing C++. The basic rule of thumb, if you are going to be writing programs for windows you use Visual Studio. Now .NET as a language isn't that bad, I actually like it. What I hate is the Virtual Machine nonsense, that only works on Windows Systems, yet it is still virtualized so it runs slow. It combines the worst attributes of the VB6 world and the Java World. If Visual Studio gave people a non .NET option for VB (a VB 7 per say) then I would expect VB 6 dyeing out and .NET wouldn't have caught on. It would have been an other J++
Java success is in the fact you can write code and run it nearly every modern system out there. And you code isn't scripted but in a way that can be closed source (Not all developers want their code Open Source) Also Java has a good set of quality IDEs Netbeans, Eclipse are a few of them, and they are really good at Java Coding.
Why do we want VB6 to die more then the others?
1. It is a platform for unstable applications. VB6 Apps have a tendencies of getting corrupted and random deaths where you need to reinstall them.
2. Visual Studio 6 needs to run on Newer OS's Windows 7 64 bit... Windows 8?
3. You cannot buy the media/licenses directly anymore. If you are going to grow you company you cannot stick on a tool where you cannot get legal licenses as your company grows.
4. Young Whipper Snappers don't want to use it. (We are at a point where we have a lot of software developers retiring) And we need to replace them with younger blood. The problem is the young guys do not want to use it.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
VB6 has staying power for one major reason -- you can do about half of the programming by dragging-and-dropping. You have a visual IDE, where you can plop stuff onto a form, 'wire them up' with a few lines of code, and you are the rock-star of the day. For those of you who are visually oriented, it is a huge plus to write in the language. And if it didn't do that one thing you needed out of the box, you would go and buy some 3rd party's OCX, which would show up on the toolbar, and you plopped that onto the screen. Additionally, working with Databases was pretty much as easy as Access -- again, drag-drop stuff, enter the database name, and away you went. Do date, there really isn't any IDE/Language that has targeted this audience of people who wanted to do RAD in this visual manner. So many of the web-targeted languages you need to visualize everything for the computer (which some people really have a hard time with). Many of the other modern application development languages require a lot more programming to do the same thing.
My personal (potentially biased) explanation is that RoR forces you to dive into the underlying technologies (which can be really raw) once you try to implement something beyond the tutorial.
The other thing is, the underlying complexity of an "desktop app" is much lower than a web app, which is really a distributed system comprising many components...
Don't quote me on this.
This "bus driver" has a PhD in computer science and in my weaker days wrote code that still exists in various linux distros. i started a company 15 years ago with some vb apps and, guess what.. the vb6 apps still sell. over $4 million per year with my staff of 5. So, you know, call me a "bus driver", call it a "scripting language", and any other insults you want - I can take it. Or rather, I just wont care.
No one cares about .Net applications
I'm afraid you are completely wrong in that, .Net is a quickly growing market among small to medium businesses (the type of work that I see), and is already widely used in the large business area. VB6 is certainly hanging on well past life support, but that doesn't mean people aren't moving on.
The VB6 compiler produced native code. Most of the sloth came from the runtime libraries, and most of that from string handling : rolling your own StringBuilder class fixes most of that.
Java has the same issues, also using an immutable string class, but they fixed it by hacking the compiler to recognise where you are doing string concatenation in a loop and make a StringBuilder out of it instead. .NET also produces native code, eventually.
Performance problems in any of them are usually down to bad algorithms, or using a mass of bloaty libraries to compensate for a lack of time.
This is why when I develop applications with VB6, if I'm not satisfied with the speed, I typically use ASM as a back engine, and have the main interface and said engine communicate back and forth via commandlines and/or files. It might not be the most elegant solution, but it works in terms of stability and usability.
I am not sure the stereotypes Platt is describing really make sense. I know plenty of non-vb6 coders who work 40 hour weeks and actively avoid jobs where they must work evenings and weekends (myself included). I would imagine that plenty of vb6 programmers started working these kinds of hours after the .com bubble popped, for fear of losing their jobs otherwise (until they burned out, of course).
A career in tech is bad enough as it is....no opportunity for upward mobility without shifting to a completely different role that requires a completely different set of skills and training....a tight ceiling on the salary....spending most of your day typing on a computer rather than socializing...and so on. Working long hours without at least collecting overtime pay for them just adds injury to insult.
The only reasons I can imagine that people put up with that are:
1) you are programming games or something and as such really enjoy the work, and would work such crazy hours on your hobby projects completely unpaid if you could
2) You are making half a million a year (or more)
3) you are easy to bully and don't have any social skills (hence no social life) and no sense of your actual market value, so you let yourself be exploited.
I can't imagine that the majority of software developers fall into these categories. They simply must be the minority. Or am I just being totally egocentric and ignorant here?
3, and 4 are fair points. 1 and 2 are just wrong. VB6 apps are no worse than any other, and you can run VB6 on windows 7 64bit with a patch that you can download from MS.
I do think that VB7 would have killed .NET dead, which is exactly why they didn't make one. I understand MS wanted the original .NET to be much more VB compatible, but the .NET guys didn't (or rather couldn't) want to do this, they wanted to make their own version of Java and nothing was going to stop them. Well, until today when MS has realised .NET performance and efficiency is crap and they need to go back to native code. Maybe now they'll make a VB7 that is geared toward quick-n-easy Metro apps, then Windows8 might actually become popular.
Java itself is a simple and clean language, and is not that bloated by current standards.
I think it gets a bad rap, because people think 'applets', or 'J2EE', or worse yet, the countless piles of crap foisted upon them at work, known as 'enterprise software'.
The objective reality, I think, is quite different from often-mistaken perception -- I've seen both garbage and masterpieces written in everything from Ruby, to VB6, to Java, to Perl. Depends on the programmer, not the tools or languages.
It is a platform for unstable applications. VB6 Apps have a tendencies of getting corrupted and random deaths where you need to reinstall them.
Been using it since release. This is total BS. It is very stable.
Visual Studio 6 needs to run on Newer OS's Windows 7 64 bit... Windows 8?
What? I'm still running it on Win XP, Server 2003, 2008, Vista, and 7. WTF?
No, you're quite right. Most coders, even most of the extremely good and very productive ones, work the working week then go on to have some sort of a life outside work.
Working insane hours is acceptable for short bursts at crunch time. If it's consistently expected or needed then it's a management failure.
The objective is to spread FUD, taking advantage of a mass of lost, blind followers that had given up their theological believes to embrace a new, technological religion.
Java is not bloated, neither slow or sluggish or whatever. But your applications can be bloated, slow and sluggish if you hire bloated, slow and sluggish minded programmers to do the job. .NET is not better than anything, but it's not worst neither. The Object Model shines sometimes (Microsoft hired the guy behing Borlands's Object Pascal Windows Library). I would even consider a .NET career if it was not backed up by Microsoft - I'm already burned by Microsoft technologies twice, I can pass the third. =]
Ruby? Marvelous language. I loved every day I spent learning it. But I took Python to day to day business - I ended up more productive (and my services, less machine demanding) using Python. Nice API, by the way - but the lack of threading sucks.
I also made some good projects in VB6 and Perl also. I prefer not doing it again, however.
VB6 is, really, very limited on modern programming technics (but something can be done, nevertheless - I just think I can do it easier on another language).
Perl is too much different from anything else to make me fell comfortable on it.
On the long run, no matter how many languages I deal with - the unique one that is omnipresent is C. It saved my sorry ass countless times.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
Now .NET as a language isn't that bad, I actually like it..
.NET as a language isn't that bad because it's not a language. It's a frikkin framework.
Some apps are WYSIWYG. Some others are WYSIWTF.
Just because Bonamassa can make good music from a $30 guitar doesn't mean the guitar isn't shit. The fact that a good programmer can write a good programing a crappy language doesn't mean the language isn't bad. It just means the programmer is good enough to overcome the warts.
Dilbert RSS feed
How I envy the guy who will have to port your software to another OS or architecture /s
Dilbert RSS feed
...fully object oriented thingy called VB.Net ... the overhead of that object oriented nonsense didn't make any sense at all ... The fatal mistake that Microsoft made with VB.Net is that it was completely backwards incompatible ... No one cares about .Net applications
You don't seem to have any idea what you're talking about.
(1) VB6 is an object-oriented language. Its support is poor--eg. no inheritance, clunky syntax--but programmer-defined classes exist. If you meant just the new OO features you should have said so--your wording is imprecise throughout. .NET class library is very good and is a huge potential "appreciable benefit" to upgrading. .NET and VB6 are comparable in speed (except loading times, .NET is worse there). Which wins depends on precisely what you're doing. For math-heavy problems, .NET is often much faster. But honestly, why the hell do you care about the speed (/memory use/whatever you meant by "overhead") of VB6 apps? It's almost always irrelevant in light of user input delays.
(2) VB6 has no class library to speak of--you had to write your own routine or hack together a ListBox to sort a string array. That should be a couple lines of code. Forget hash tables, queues, etc.--you have to implement it all yourself or find somebody else's random crap, which is wildly inefficient. The
(3)
(5) .NET is not even remotely dead, so no "fatal mistake" was made. .NET apps. Glance at the Tiobe index, for instance. .NET Metro style apps. Converting an existing desktop app may or may not require significant work. Your backend will be mostly to entirely reusable, so you won't have to "rewrite everything".
(6) Lots of people care about
(7) You'll be able to create
(8) You greatly exaggerate the backwards compatibility problems and you know it. Some large projects are suited to automated/assisted migration; just read these zillion testimonials. It's far from perfect, but it's also far from nothing.
You do have at least a few good points--lots of businesses absolutely rely on very old technology and wouldn't upgrade without support; Microsoft's chances of getting a significant mobile presence are slim. You came close to the truth behind the continued success of VB6: people don't want to learn new systems and some people are stuck maintaining old ones that are too difficult to convert. Most of your points are garbage though.
Yeah just don't try to free lots of memory in VB6!!!
Go ahead and try it...
or .net or java or any common application like firefox or chrome. Modern development doesn't free memory, it restarts/launches a new process. Garbage collection has been a joke since before we started measuring ram in gb instead of mb.
It's too bad that Delphi didn't win out. It was a much better language/environment that VB6.
Zoid.com
Exactly. VB6 is crap, but when the customer has an application they like, with lots of functionality, they are NOT going to pay to re-write it in something else just because some developer would prefer to use something different. If they need a minor change they are going to find somebody to spend a day or two making the changes in VB6, no matter how many developers keep telling them they need to spend a few weeks or months to update it to some other language.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
Do date, there really isn't any IDE/Language that has targeted this audience of people who wanted to do RAD in this visual manner.
Wrong. There's Delphi. Say what you want about Pascal or OOP, but it is just as easy to program with as VB, it has an extensive third party component selection being actively developed (to do whatever you want, from serial communication to image processing and GUI components) and it is, somehow, still being sold and supported.
When .NET came around, its users were praising the ease of GUI development, something that Borland users already became accustomed to during the previous 10 years or more (with both Delphi and C++ Builder). With no dynamic libraries or virtual machines to depend on, every executable runs natively with the visual component library -- VCL -- that can be statically compiled in it.
Unfortunately tho, Borland changed its business focus and sold the whole thing (except the VCL) to CodeGear. The new VCL developed by CodeGear is meant to be compatible with the old Borland one, but it still has compatibility problems and, in general, is bigger. The last Borland-produced version of Delphi is the 2006 one and that's what I'm still using today for quick drag and drop GUI projects (when there's no need to spend more than 5 minutes drawing a GUI). And I know several people making tons of money selling and developing DB based programs with versions even older (Delphi was originally developed to provide an easy to use interface to DBs, that's why it is named after an "oracle").
I just don't get why so many find it hard to believe VB 6 has such long legs. it did ONE job and it did that job fucking brilliantly, which was to make an easy to use GUI front end to a DB, that's it, that's all. This is what MSFT fucked up with with .NET because frankly ALL of the VB 6 I've seen being used and being built really was only variants on that one function.
What MSFT refused to accept was was how important one small function can be to an SMB or SOHO. There is a HELL of a lot of times a small business can use a custom GUI to a DB, everything from contacts to records can be kept in a simple DB that just needs an easy to use front end so the user doesn't have to know anything about DBs, just fill out the forms.
Finally all those "real" programmers that gnash their teeth at even the mention of the word VB? GET OVER IT, you wouldn't expect them to call a 'real"engineer when all they need is something that can be banged together out of an Erector set would you? of course not and it just so happens there is a hell of a lot of business jobs that don't need some full blown SQL DB just to get the job done. Its just like how we've all seen "applications" built out of VBA and Access, it has its little niche and as long as one doesn't try to build something outside of its little niche? Then its a perfectly valid tool.
MSFT failed with .NET because they assumed if you were doing job A that you would want to learn to have the power to do jobs B-K, when in reality frankly there were tons of guys that frankly only needed to do job A so B-K were simply overkill and pointless. That is why VB 6 has such long legs, frankly there hasn't been any other language that filled the SMB small DB niche quite as well as VB 6.
ACs don't waste your time replying, your posts are never seen by me.
".NET is actually awesome,"
SUbjective, although I agree.
" especially when used with C#"
Subjective
". Java is too much bloat and slow and needs to die."
A ohhible sentence that is false
"But .NET is awesome and targets all PC, XBOX360 and Windows Phone 7"
Subjective
" And you can use the best IDE on the planet, Visual Studio, to develop."
False. It lacks several thing much older IDEs had.
So the only to things that aren't opinion are wrong.
The Kruger Dunning explains most post on
Finally all those "real" programmers that gnash their teeth at even the mention of the word VB? GET OVER IT, you wouldn't expect them to call a 'real"engineer when all they need is something that can be banged together out of an Erector set would you? of course not and it just so happens there is a hell of a lot of business jobs that don't need some full blown SQL DB just to get the job done.
I'd be fine with that. Except that those little projects that just need to be banged together out of an erector set have a habit of growing, and becoming "business critical". They soon exceed the skills of those who banged them together, and they need to call a "real engineer" in to make it work again. Frequently, the existing software doesn't do exactly what it's meant to, or what the documentation (if there is any) says it does, and nobody wants to give any design criteria are "do what the old one does, but better".
In short, the reason "real programmers" hate it, is because sooner or later, it ends up being their problem.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
In short, the reason "real programmers" hate it, is because sooner or later, it ends up being their problem.
In my business we call that a sales opportunity. When your job is to fix things, the more broke they are, the more money you can make.
-- I have a private email server in my basement.
In my business we call that a sales opportunity. When your job is to fix things, the more broke they are, the more money you can make.
If you were a contractor called in to fix it, I'd agree. If you're an in-house developer whose real job isn't to fix things, but to create new things, getting pulled off whatever job you were doing in the first place to fix someone else's mess is a PITA - and you don't make any more money.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face