4 ms·

Yep. I worked at a place that fired almost its entire programming staff because they insisted on using Visual C++ to build a CRUD app, while a team of contracto

Yep. I worked at a place that fired almost its entire programming staff because they insisted on using Visual C++ to build a CRUD app, while a team of contractors built a prototype in Visual Basic. Needless to say, the VB app worked fine and became the product.

diarrhea 4y ago
If you don't mind, would you explain this more? I don't understand the implications; VB does sound "worse" than Visual C++ for such a job, from an outsider perspective?
- koonsolo 4y ago
  In C++ you have to manage your own memory. Why would you want to do that when you're simply pushing data around. I wouldn't choose VB myself, but when it's between VB and C++ for simple data pushing, I would indeed choose VB. Let's say it like this: if you need to move stuff, would you choose a F1 car or a minivan. I would pick the minivan.
- NonNefarious 4y ago
  No problem. At the time, Visual C++ lacked several important OCX controls that were included with VB, so they had to be hand-coded. If you were building an application that does little more than populate forms with data from a database and then update the database, VB was totally adequate. The most important part of the job was the DB and query design.
- CRConrad 4y ago
  > VB does sound "worse" than Visual C++ for such a job Huh? No no, on the contrary: Straightforward CRUD apps, that's exactly what VB was built for and excels at. Only Delphi is better. The thing about "Visual" C++ is that it isn't (or at least wasn't, last I looked) really very visual at all. And that sucks for building simple in-house CRUD apps, where the VB / Delphi drag-and-drop UI builder paradigm is a huge productivity multiplier.
mechanical_bear 4y ago
Why is this “needless to say”, as if it should be apparent to anyone?
- NonNefarious 4y ago
  Because a CRUD app doesn't require any serious computing performance from the application, making C++ unnecessary. If another implementation won the race to functional completion, then... needless to say... it was the one to go with. Today you'd probably just use browser-based UI. Also if you've spent time in corporate development (rather than a software company), I think this scenario is a common one. If you show management a prototype that works, they're going to ask why we don't just make that the product. And if you don't have a good reason... you don't have a good reason.

diarrhea 4y ago

If you don't mind, would you explain this more? I don't understand the implications; VB does sound "worse" than Visual C++ for such a job, from an outsider perspective?

koonsolo 4y ago
In C++ you have to manage your own memory. Why would you want to do that when you're simply pushing data around. I wouldn't choose VB myself, but when it's between VB and C++ for simple data pushing, I would indeed choose VB. Let's say it like this: if you need to move stuff, would you choose a F1 car or a minivan. I would pick the minivan.
NonNefarious 4y ago
No problem. At the time, Visual C++ lacked several important OCX controls that were included with VB, so they had to be hand-coded. If you were building an application that does little more than populate forms with data from a database and then update the database, VB was totally adequate. The most important part of the job was the DB and query design.
CRConrad 4y ago
> VB does sound "worse" than Visual C++ for such a job Huh? No no, on the contrary: Straightforward CRUD apps, that's exactly what VB was built for and excels at. Only Delphi is better. The thing about "Visual" C++ is that it isn't (or at least wasn't, last I looked) really very visual at all. And that sucks for building simple in-house CRUD apps, where the VB / Delphi drag-and-drop UI builder paradigm is a huge productivity multiplier.

mechanical_bear 4y ago

Why is this “needless to say”, as if it should be apparent to anyone?

NonNefarious 4y ago
Because a CRUD app doesn't require any serious computing performance from the application, making C++ unnecessary. If another implementation won the race to functional completion, then... needless to say... it was the one to go with. Today you'd probably just use browser-based UI. Also if you've spent time in corporate development (rather than a software company), I think this scenario is a common one. If you show management a prototype that works, they're going to ask why we don't just make that the product. And if you don't have a good reason... you don't have a good reason.