4 ms·

Thats not my recollection of the era. VB was was widely scorned but it was incredibly productive. At my workplace at the time, when smalltalk collapsed as a v

Thats not my recollection of the era. VB was was widely scorned but it was incredibly productive. At my workplace at the time, when smalltalk collapsed as a viable dev environment, it was largely replaced with VB pointing at the sybase databases we had. The smalltalkers scoffed, but the speed the VB guys got things done killed everything else. I ended up moving to a team that built a distributed trading system on DCOM, c++ and VB and while the tech wasn't lovable, it sure worked better than corba and java. Its easy to forget what a monster VB was. Java took forever to mature in comparison. That websphere nonsense was a huge distraction for people who just wanted a crud app.

Stratoscope 5y ago
As one of the original developers of VB, what you wrote here really touched me. What you're describing was exactly what we hoped to facilitate.
vanderZwan 5y ago
Your counterargument applies to your work place only though, do you know of other companies that did the same?
- matwood 5y ago
  I can't speak to smalltalk, but I can for Java vs. VB. VB was big in Microsoft shops. Java wasn't anywhere close to as easy or viable for desktop CRUD apps then (could be argued if ever). Language aside, I could argue that VB6 was the closest the industry has gotten to low/no code for complex CRUD apps.
  - baq 5y ago
    > Language aside, I could argue that VB6 was the closest the industry has gotten to low/no code for complex CRUD apps. cries in Delphi tears
  - dragonwriter 5y ago
    > Language aside, I could argue that VB6 was the closest the industry has gotten to low/no code for complex CRUD apps. Access (with integrated VBA for what code is needed, and the whole market of similar desktop databases Access ended up dominating and eating, like FoxPro, Paradox, etc., each usually with their own proprietary language) is and were much closer to low-code/no-code for that than VB6; you could generally do simple CRUD completely no-code and complex CRUD much lower-code than with VB6 (since they generally included not only code-free UI design tools but also code-free and low-code DB modeling tools).
    - matwood 5y ago
      Great point. In my mind I often lump VB (pre .net) together with Access since so much of the VBA was transferable. A common workflow was to have Access + VBA, until it go unwieldy, then VB + Access, and finally VB + mssql.
      - p_l 5y ago
        And a lot of the time you could just as well embed pieces in other languages in your Access application connected to MSSQL (or oracle or whatever)
pjmlp 5y ago
I used VB 3, VB 6, Delphi 1.0, and C++ Builder. My first VB experience was porting a MS-DOS Clipper application to Windows 3.x. So I also have some recollations of my own, like using Smalltalk/V and Oracle Forms with a VB like environment based on PL/SQL. Yet, most consultancy being done by the likes of IBM and friends wasn't based on VB.
- chipotle_coyote 5y ago
  I don't think it's the consultancy that's under question -- it's the question of what RAD tools that companies that weren't necessarily "software first" reached for when they were working on stuff in-house. Banks, manufacturing companies, telephone companies, places that decided to roll their own rather than call up IBM or Accenture (well, whatever Accenture's predecessor was). I worked at a place like that in the 1990s, a successful CLEC with a huge IT department that wrote their own custom software for order tracking and sales management -- and they wrote it in Visual Basic and Access. That's a market that Smalltalk might have been extremely successful in, but it really was basically owned by VB/VBA in the 1990s.
  - pjmlp 5y ago
    My perspective is from the Banks, manufacturing companies, telephone companies, places that decided to call up IBM or Accenture (they already existed in 1990's).
acegopher 5y ago
My recollection matches yours. Smalltalk was too expensive and hard to program user-facing apps as quickly as VB or C++ with MFC. So front-ends were either VB or C++/MFC if speed was needed on the front end, and C++/DCOM on the back end.

Stratoscope 5y ago

As one of the original developers of VB, what you wrote here really touched me. What you're describing was exactly what we hoped to facilitate.

vanderZwan 5y ago

Your counterargument applies to your work place only though, do you know of other companies that did the same?

matwood 5y ago
I can't speak to smalltalk, but I can for Java vs. VB. VB was big in Microsoft shops. Java wasn't anywhere close to as easy or viable for desktop CRUD apps then (could be argued if ever). Language aside, I could argue that VB6 was the closest the industry has gotten to low/no code for complex CRUD apps.
- baq 5y ago
  > Language aside, I could argue that VB6 was the closest the industry has gotten to low/no code for complex CRUD apps. cries in Delphi tears
- dragonwriter 5y ago
  > Language aside, I could argue that VB6 was the closest the industry has gotten to low/no code for complex CRUD apps. Access (with integrated VBA for what code is needed, and the whole market of similar desktop databases Access ended up dominating and eating, like FoxPro, Paradox, etc., each usually with their own proprietary language) is and were much closer to low-code/no-code for that than VB6; you could generally do simple CRUD completely no-code and complex CRUD much lower-code than with VB6 (since they generally included not only code-free UI design tools but also code-free and low-code DB modeling tools).
  - matwood 5y ago
    Great point. In my mind I often lump VB (pre .net) together with Access since so much of the VBA was transferable. A common workflow was to have Access + VBA, until it go unwieldy, then VB + Access, and finally VB + mssql.
    - p_l 5y ago
      And a lot of the time you could just as well embed pieces in other languages in your Access application connected to MSSQL (or oracle or whatever)

pjmlp 5y ago

I used VB 3, VB 6, Delphi 1.0, and C++ Builder. My first VB experience was porting a MS-DOS Clipper application to Windows 3.x. So I also have some recollations of my own, like using Smalltalk/V and Oracle Forms with a VB like environment based on PL/SQL. Yet, most consultancy being done by the likes of IBM and friends wasn't based on VB.

chipotle_coyote 5y ago
I don't think it's the consultancy that's under question -- it's the question of what RAD tools that companies that weren't necessarily "software first" reached for when they were working on stuff in-house. Banks, manufacturing companies, telephone companies, places that decided to roll their own rather than call up IBM or Accenture (well, whatever Accenture's predecessor was). I worked at a place like that in the 1990s, a successful CLEC with a huge IT department that wrote their own custom software for order tracking and sales management -- and they wrote it in Visual Basic and Access. That's a market that Smalltalk might have been extremely successful in, but it really was basically owned by VB/VBA in the 1990s.
- pjmlp 5y ago
  My perspective is from the Banks, manufacturing companies, telephone companies, places that decided to call up IBM or Accenture (they already existed in 1990's).

acegopher 5y ago

My recollection matches yours. Smalltalk was too expensive and hard to program user-facing apps as quickly as VB or C++ with MFC. So front-ends were either VB or C++/MFC if speed was needed on the front end, and C++/DCOM on the back end.