Hacker News Reader

Comment by smackeyacky | Hacker News Reader

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.

View on HN

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.

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.

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).

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.

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

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.

> 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

> 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).

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.

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)

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.

Reply on news.ycombinator.com