5 ms·

For smaller projects, VB6 was great. I wrote a number of tools with it. For anything large-scale, things could get out of hand quickly. I remember having to wor

For smaller projects, VB6 was great. I wrote a number of tools with it. For anything large-scale, things could get out of hand quickly. I remember having to work on localising a VB4-based ERP system that was very slow, unwieldy and full of spaghetti code.

david927 4y ago
And in the 90's, what people would do is to do the prototype with VB and expect to write the app in something else. But then the executives would see it, think it's 80% done because the UI was done, and push forward with it in VB. Or it would start out as a small, niche app in VB and then grow in scope. Either way, what would start off rationally would end up in chaos. Part of that was the language, and Microsoft is to blame there; the fix, C#, came too late. But the other, larger part was the failure of component development. And that's what people miss and that's what still remains to be solved.
- toyg 4y ago
  > the fix, C#, came too late Because it wasn't a fix for VB - it was just the answer to Java. Somewhat unfortunately, that "answer" swallowed the whole MS development ecosystem, and the VB world never really recovered.
  - david927 4y ago
    I'd argue. I think it was both. Yes, it was an answer to Java but remember, VB apps didn't scale. They exploded at scale. And no matter how much you, as an organization, promised yourself you wouldn't scale up that VB app, it kept happening. So it was also an attempt to try to fix that.
Sohcahtoa82 4y ago
When I was young and stupid I was trying to learn game development in VB6. I had a type library that provided bindings for DirectX. This was in the late 90s, so I would have been on Windows 98. I learned quickly how SLOW VB was, but was in denial about it. I wanted to make it work, but anything that required more than a few lines of logic made it impossible to maintain even 30 fps. At the time, though, I was afraid of C/C++. I thought "Those languages are too complicated! Why would anyone use them when VB is so simple?" Yeah...I learned.
- Zardoz84 4y ago
  Back to these times. I try to remake a N body problem simulator. I was trying to imitate an old DOS program called "GRAVITY.EXE" on VB6 I throw it, when I saw that my VB6 was slower that the old 16 bit DOS program, and that setting the timer control to throw events too fast, could make Windows unresponsive.
- shever73 4y ago
  In my naivety at Windows software development, I wrote an animated screensaver in VB6. It performed about as well as you just described!
- signaru 4y ago
  I used to have an irrational fear for curly braces and semicolons, given BASIC looks clean and simple. I see that now in some young programmers who try to stick to Python. Interestingly, seeing Rust code for the first time also reminded me of that.
starik36 4y ago
> unwieldy and full of spaghetti code When I was young, I saw the same until I worked with a team of professional devs and the code was clean and performant and easy to get around in. > VB4-based ERP system that was very slow Yep. VB4 was made for the transition from Windows 3.1 to 95. The first effort was good enough but not great. IIRC, it compiled to byte code and then a runtime would interpret it. Once VB5 came out with native compilation, the resulting code became very snappy.

david927 4y ago

And in the 90's, what people would do is to do the prototype with VB and expect to write the app in something else. But then the executives would see it, think it's 80% done because the UI was done, and push forward with it in VB. Or it would start out as a small, niche app in VB and then grow in scope. Either way, what would start off rationally would end up in chaos. Part of that was the language, and Microsoft is to blame there; the fix, C#, came too late. But the other, larger part was the failure of component development. And that's what people miss and that's what still remains to be solved.

toyg 4y ago
> the fix, C#, came too late Because it wasn't a fix for VB - it was just the answer to Java. Somewhat unfortunately, that "answer" swallowed the whole MS development ecosystem, and the VB world never really recovered.
- david927 4y ago
  I'd argue. I think it was both. Yes, it was an answer to Java but remember, VB apps didn't scale. They exploded at scale. And no matter how much you, as an organization, promised yourself you wouldn't scale up that VB app, it kept happening. So it was also an attempt to try to fix that.

Sohcahtoa82 4y ago

When I was young and stupid I was trying to learn game development in VB6. I had a type library that provided bindings for DirectX. This was in the late 90s, so I would have been on Windows 98. I learned quickly how SLOW VB was, but was in denial about it. I wanted to make it work, but anything that required more than a few lines of logic made it impossible to maintain even 30 fps. At the time, though, I was afraid of C/C++. I thought "Those languages are too complicated! Why would anyone use them when VB is so simple?" Yeah...I learned.

Zardoz84 4y ago
Back to these times. I try to remake a N body problem simulator. I was trying to imitate an old DOS program called "GRAVITY.EXE" on VB6 I throw it, when I saw that my VB6 was slower that the old 16 bit DOS program, and that setting the timer control to throw events too fast, could make Windows unresponsive.
shever73 4y ago
In my naivety at Windows software development, I wrote an animated screensaver in VB6. It performed about as well as you just described!
signaru 4y ago
I used to have an irrational fear for curly braces and semicolons, given BASIC looks clean and simple. I see that now in some young programmers who try to stick to Python. Interestingly, seeing Rust code for the first time also reminded me of that.

starik36 4y ago

> unwieldy and full of spaghetti code When I was young, I saw the same until I worked with a team of professional devs and the code was clean and performant and easy to get around in. > VB4-based ERP system that was very slow Yep. VB4 was made for the transition from Windows 3.1 to 95. The first effort was good enough but not great. IIRC, it compiled to byte code and then a runtime would interpret it. Once VB5 came out with native compilation, the resulting code became very snappy.