3 ms·

Problem with VB6 was that for small projects it was fine but for medium to large projects it gets out of hand very quickly. For example when you drag and drop

Problem with VB6 was that for small projects it was fine but for medium to large projects it gets out of hand very quickly. For example when you drag and drop toolbar items onto your form it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget so after a while just looking at the code you started to get Label1.Text = "blah". I seen that in just about every project and one I remember done by a Chinese dev with poor English he left all the controls with the boilerplate names and so it was impossible to reason about what was happening. Componentisation was also a problem in that you tended to have all your code connected directly to the form. So if you had a large form that done complex stuff it wasn't unusual to have a multi thousand line long form file. Separation of concerns was a problem in that again the code was attached to a form so you found UI code mixed in with proper business logic. This becomes very messy over time and tends to create very large event handlers the more a project grows. It was basically impossible to unit test which makes refactoring very risky. On large projects what generally happens then is that no one is willing to refactor anything as they don't really know all the scenarios. Over time this leads to code rot. It only ran on windows, while I'm sure there are ways to make it run under linux the main support was for windows and most orgs stuck to that. This ties in with the fact that you had to install the thing on your P.C. businesses hated this and still do. Things like people uninstalling it or problems locally with permissions and suchlike were rampant. Similarly updating was a pain on large projects you have to have something central install and do the update. Scalability was problematic on large projects especially since the forms app would often directly connect to the database. That meant the more user = more connections which on large project meant problems. The "solution" was some service or api which the app talked to but at that point it's no longer vb6 doing the heavy lifting and it's just become a UI. Small little tools or prototype apps was were vb6 shined brightly.

zozbot234 4y ago
> but for medium to large projects it gets out of hand very quickly. Yup, it was really built without sufficient attention to the "programming in the large" featureset, much like those BASICs of old. Of course this became less of an issue in VB.NET that was pretty much a C# equivalent. > it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget The "Object Inspector" interface to form-element properties (including its identifier in code!) was very unintuitive, so this was a predictable outcome. > Componentisation was also a problem in that you tended to have all your code connected directly to the form. Yes, because it was difficult to have a full global view of the code that might drive a refactoring. Each form element and event would bring up its own tiny window of code.
jjkaczor 4y ago
"So if you had a large form that done complex stuff it wasn't unusual to have a multi thousand line long form file." Just a small quibble - you would typically move shared-code into seperate module files. The other biggest challenge we had was when trying to build a larger solution that worked with COM dependencies amongst multiple projects, you would occasionally have to do a clean-build which break binary compatibility (don't forget to do a registry cleanup!), and that mean "compiling" your tree manually, from the base level components upwards. That got much easier if you could get your hands on a Microsoft MCS tool called, VBBuilder. (I can't remember if it ever was available for open/free download)
badsectoracula 4y ago
Most of that stuff is really up to the programmer and not due to the tool. While i agree that VB6 wasn't a good tool to write big projects on, it wasn't because of the issues you mentioned (since those would apply to something like Delphi and Lazarus too and they are certainly fine for making large projects on), it was because at its core it was a rather simple and limited scripting language bolted on a WYSIWYG form designer with some database stuff latched on via an extension system. If anything some aren't even issues but features - e.g. being able to have code attached directly to events speeds up development a lot and if you need to put it somewhere else (IME the case where this isn't necessary is more common than the case where it is) you can simply have your handler call some method in another file so you can keep those separate.
maxbaines 4y ago
For me boilerplate names is an issue for whatever object orientated language you choose, unless you correct it in the dev cycle.

zozbot234 4y ago

> but for medium to large projects it gets out of hand very quickly. Yup, it was really built without sufficient attention to the "programming in the large" featureset, much like those BASICs of old. Of course this became less of an issue in VB.NET that was pretty much a C# equivalent. > it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget The "Object Inspector" interface to form-element properties (including its identifier in code!) was very unintuitive, so this was a predictable outcome. > Componentisation was also a problem in that you tended to have all your code connected directly to the form. Yes, because it was difficult to have a full global view of the code that might drive a refactoring. Each form element and event would bring up its own tiny window of code.

jjkaczor 4y ago

"So if you had a large form that done complex stuff it wasn't unusual to have a multi thousand line long form file." Just a small quibble - you would typically move shared-code into seperate module files. The other biggest challenge we had was when trying to build a larger solution that worked with COM dependencies amongst multiple projects, you would occasionally have to do a clean-build which break binary compatibility (don't forget to do a registry cleanup!), and that mean "compiling" your tree manually, from the base level components upwards. That got much easier if you could get your hands on a Microsoft MCS tool called, VBBuilder. (I can't remember if it ever was available for open/free download)

badsectoracula 4y ago

Most of that stuff is really up to the programmer and not due to the tool. While i agree that VB6 wasn't a good tool to write big projects on, it wasn't because of the issues you mentioned (since those would apply to something like Delphi and Lazarus too and they are certainly fine for making large projects on), it was because at its core it was a rather simple and limited scripting language bolted on a WYSIWYG form designer with some database stuff latched on via an extension system. If anything some aren't even issues but features - e.g. being able to have code attached directly to events speeds up development a lot and if you need to put it somewhere else (IME the case where this isn't necessary is more common than the case where it is) you can simply have your handler call some method in another file so you can keep those separate.

maxbaines 4y ago

For me boilerplate names is an issue for whatever object orientated language you choose, unless you correct it in the dev cycle.