VB6 - far from dead!
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
I can think of several reasons. As others have mentioned, there is legacy code. Second, not every shop has the money to switch to VB.net, even if they have the interest: if they are already maintaining a significant codebase in VB6, and already have the expertise and compiler software, and everything is working just fine, why go to the effort and cost of changing? In my experience, the computer industry is pretty conservative when it comes to changes. When I started at my current company in 1996, I was hired because I was the only applicant who admitted to knowing COBOL: they needed my skills because our enterprise database -- which had been in place and largely unchanged since the early 1980s -- was a non-relational database on a Rand-McNally minicomputer with a JCL-like form generator for the user interface that used hundreds of COBOL applets to manipulate data. The one and only reason we got rid of it in 1999 was federal mandate to "address the Y2K problem" in the financial industry. Thirteen years later, we are still using the VB6 (originally VB4) application that replaced it, although we have plans to upgrade to a VB.Net version in a few months that will no doubt continue in use for at least another decade.
-
Rama Krishna Vavilala wrote:
Why not?
VB6 has not culturally been a toolset/language used by people with performance requirements.
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
Nishant Sivakumar wrote:
VB6 has not culturally been a toolset/language used by people with performance requirements.
FTFY. Sorry couldn't resist :laugh:
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood 'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
Nishant Sivakumar wrote:
Why are people still using this? I mean why not VB.NET?
There is legacy code unfortunately written in VB6 that is still out there. I know of some software shops I've worked with that have cited the move from VB6 to VB.NET is something they have planned to do, and the move for some of them have been slow because of money and other reasons leaning towards office/interdepartment politics.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
-
Oh I don't know about that. I wish I had my old Mach1 back, and I would most certainly still race it.(probably a good reason for me NOT to have it back, truth be told) EDIT: because I apparently cant spell today.
Let's face it, after Monday and Tuesday, even the calendar says WTF! Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow. You can't scare me, I have children.
Did you mean the "Mach 1"?
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) -
Did you mean the "Mach 1"?
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011)!@#$#@!$ I'm going back to bed. I knew that didn't look right and typed it anyway.
Let's face it, after Monday and Tuesday, even the calendar says WTF! Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow. You can't scare me, I have children.
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
This does not answer your exact question, but I do think it's important to remember that VBA and Office automation are both tightly coupled with some aspects of the "Classic VB" architecture. I think that this will probably continue to be true for some time. VBA is very much a member of the "Classic VB" language family, and until Microsoft offers something similar that's built on more modern underpinnings, people will continue to do VBA development, especially with Microsoft Access. More generally, Office automation is based on COM and in particular on ActiveX. I am a bit surprised this is still the case. When I first started using .NET, I expected the "PIA" wrappers used to do Office automation would get replaced with .NET-based equivalents within a reasonable time frame. This has not happened, and as a result the .NET languages do not offer a really compelling advantage for doing Office automation. If anything, VB6 (which was largely just a clever tool for commanding ActiveX components) probably still provides a better developer experience for this sort of work. Certainly this is the case if one is already familiar with VB6.
-
This does not answer your exact question, but I do think it's important to remember that VBA and Office automation are both tightly coupled with some aspects of the "Classic VB" architecture. I think that this will probably continue to be true for some time. VBA is very much a member of the "Classic VB" language family, and until Microsoft offers something similar that's built on more modern underpinnings, people will continue to do VBA development, especially with Microsoft Access. More generally, Office automation is based on COM and in particular on ActiveX. I am a bit surprised this is still the case. When I first started using .NET, I expected the "PIA" wrappers used to do Office automation would get replaced with .NET-based equivalents within a reasonable time frame. This has not happened, and as a result the .NET languages do not offer a really compelling advantage for doing Office automation. If anything, VB6 (which was largely just a clever tool for commanding ActiveX components) probably still provides a better developer experience for this sort of work. Certainly this is the case if one is already familiar with VB6.
_beauw_ wrote:
If anything, VB6 (which was largely just a clever tool for commanding ActiveX components) probably still provides a better developer experience for this sort of work. Certainly this is the case if one is already familiar with VB6.
Totally agree. VB6 was (still is) the greatest COM client ever invented.
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
-
In defence of some software houses the cost of upgrading from VB6 has been too high. Where I worked previously, their was a multiyear project to move everything from VB6 to C#, but it couldn't be done in one hit. The plan when I left was that it would take another 2-3 years.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
_beauw_ wrote:
If anything, VB6 (which was largely just a clever tool for commanding ActiveX components) probably still provides a better developer experience for this sort of work. Certainly this is the case if one is already familiar with VB6.
Totally agree. VB6 was (still is) the greatest COM client ever invented.
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
Nishant Sivakumar wrote:
Totally agree. VB6 was (still is) the greatest COM client ever invented.
Exactly... and Microsoft shows no signs of being able to do away with COM. Everything they try to do to replace COM seems to end up wrapping COM instead (and that's not so much an indictment of Microsoft as it is a simple fact of nature).
-
But upgrading VB6 (that isn't a horrible mess of spaghetti and implicit declarations that needs rebuilding anyway) to VB.net is nowhere near such a big hit, as most of the code will work with no or minor alterations.
It was decided to re-implement everything as it is mostly 5+ years old with so many modifications it would be like trying to rewire Hampton Court one plug at a time.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
If it's not broke, don't fix it.
-
Nishant Sivakumar wrote:
Totally agree. VB6 was (still is) the greatest COM client ever invented.
Exactly... and Microsoft shows no signs of being able to do away with COM. Everything they try to do to replace COM seems to end up wrapping COM instead (and that's not so much an indictment of Microsoft as it is a simple fact of nature).
-
If it's not broke, don't fix it.
-
Rama Krishna Vavilala wrote:
Why not?
VB6 has not culturally been a toolset/language used by people with performance requirements.
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
Nishant Sivakumar wrote:
Why are people still using this? I mean why not VB.NET?
- They're accustomed to VB6
- It requires less resources (think old machines)
- They're heavily invested in VB6 and can't afford to update the sourcecode to a new framework
..and some people still believe that you can only use VB6 to extend a VB6 application. One can seamlessly put some .NET in there using the Interop Forms Toolkit[^] :)
Bastard Programmer from Hell :suss:
-
I can think of several reasons. As others have mentioned, there is legacy code. Second, not every shop has the money to switch to VB.net, even if they have the interest: if they are already maintaining a significant codebase in VB6, and already have the expertise and compiler software, and everything is working just fine, why go to the effort and cost of changing? In my experience, the computer industry is pretty conservative when it comes to changes. When I started at my current company in 1996, I was hired because I was the only applicant who admitted to knowing COBOL: they needed my skills because our enterprise database -- which had been in place and largely unchanged since the early 1980s -- was a non-relational database on a Rand-McNally minicomputer with a JCL-like form generator for the user interface that used hundreds of COBOL applets to manipulate data. The one and only reason we got rid of it in 1999 was federal mandate to "address the Y2K problem" in the financial industry. Thirteen years later, we are still using the VB6 (originally VB4) application that replaced it, although we have plans to upgrade to a VB.Net version in a few months that will no doubt continue in use for at least another decade.
Excellent answer. Probably pretty close to correct also.
-
harold aptroot wrote:
VB6 not broke?
Not VB in so much as those who abuse the um... "forgiving" nature of VB6 when it comes to stuff like loose variable declaration, hell you don't even need to declare a variable to use one. :) The beauty of VB6 was that they made it simple enough that a child could use it to program. Unfortunately most of the users program like children. :~
It was broke, so I fixed it.
-
You read right! WinRT is new COM (COM with extra interfaces).
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
-
If it's not broke, don't fix it.
I agree completely; one of the reasons that we are paying for an OS is the fact that it's backward compatible. I can rely on Windows to run the first edition of Railroad Tycoon. If it was possible 30 years ago to run it, then it should be possible to run it now.
Bastard Programmer from Hell :suss:
-
it works for what it is. The thing is, an IT department may develop hundreds of line of business tools that just work. Here or there an adjustment may need to be made to the application to keep it compatible with other systems in the company that change. However, depending on the circumstances, it could be much less effort and expense to make minor modifications to an application that works than to rewrite from scratch. Then just move new application development to VB.Net or whatever language IT decides on as tools evolve.