24 ms·

VB was the one thing that most closely approached the promise of object orientation: "bolt-together," "off-the-shelf" components that you could build software w

VB was the one thing that most closely approached the promise of object orientation: "bolt-together," "off-the-shelf" components that you could build software with. In VB you could slap together a CRUD app in days, with VBXs (later renamed OCXs). I worked for a company where a bunch of programmers turned up their nose at VB and insisted on using C++, and then they got canned when the VB prototype functioned perfectly sufficiently for a production app.

grumpyprole 4y ago
When I first played with VB in the early nineties, it was also about the time Microsoft Foundation Classes was released. I compared the two approaches for building UIs and it pretty much soured my opinion of C++ for life.
- ShadowBanThis01 4y ago
  Oh man, while we got a lot done with MFC, I scorned the macro mess that VC++ generated. To this day I detest C/C++ macros and never use them in my own code. But years later, when I had to switch to the Mac and Project Builder, I couldn't believe how half-assed its integration with Interface Builder was. You couldn't even drag from a control in your UI layout to your view's source code to generate a code stub. You had to manually type stuff like IBOUTLET. And there was no bi-directional updating either, of course. It has gotten a lot better since. Meanwhile, whereas I used to love the Visual Studio IDE itself, I find the same ridiculous bugs in it that I reported 20 years ago...
omnibrain 4y ago
> VB was the one thing that most closely approached the promise of object orientation: "bolt-together," "off-the-shelf" components that you could build software with. I think Delphi perfected it with the data aware components. If you had a DB you could throw together a CRUD application with several screens with tablegrids and edit fields without any code at all. Even Master:Detail relations are taken care of. (Of course it's not pretty and it's going to miss validation, etc...)
- petepete 4y ago
  Delphi's data aware components were power tools. It didn't take much longer than building something in Access, but dead easy to plug it into a RDBMS; extremely fast to work with; stable, simple to deploy. As I remember, making validation errors pretty was a bit of a chore, but on most of our backend stuff we just showed the SQL error and it usually made sense.

grumpyprole 4y ago

When I first played with VB in the early nineties, it was also about the time Microsoft Foundation Classes was released. I compared the two approaches for building UIs and it pretty much soured my opinion of C++ for life.

ShadowBanThis01 4y ago
Oh man, while we got a lot done with MFC, I scorned the macro mess that VC++ generated. To this day I detest C/C++ macros and never use them in my own code. But years later, when I had to switch to the Mac and Project Builder, I couldn't believe how half-assed its integration with Interface Builder was. You couldn't even drag from a control in your UI layout to your view's source code to generate a code stub. You had to manually type stuff like IBOUTLET. And there was no bi-directional updating either, of course. It has gotten a lot better since. Meanwhile, whereas I used to love the Visual Studio IDE itself, I find the same ridiculous bugs in it that I reported 20 years ago...

omnibrain 4y ago

> VB was the one thing that most closely approached the promise of object orientation: "bolt-together," "off-the-shelf" components that you could build software with. I think Delphi perfected it with the data aware components. If you had a DB you could throw together a CRUD application with several screens with tablegrids and edit fields without any code at all. Even Master:Detail relations are taken care of. (Of course it's not pretty and it's going to miss validation, etc...)

petepete 4y ago
Delphi's data aware components were power tools. It didn't take much longer than building something in Access, but dead easy to plug it into a RDBMS; extremely fast to work with; stable, simple to deploy. As I remember, making validation errors pretty was a bit of a chore, but on most of our backend stuff we just showed the SQL error and it usually made sense.