4 ms·

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)