(When you say "IT work" - are you referring to software-engineering work specifically - or "IT" in general? (I'm personally not a fan of "IT" as a term at all because it's unhelpfully vague[1]).
I wasn't comparing them directly like that.
My point is that in the 1990s if you used VB in production systems then you would effectively be forced into investing a lot of company resources - and mental effort - into all kinds of entirely disconnected approaches for formalising, proving and even testing your system. Whereas the state of the art for formalising SWE work today currently lies in tools like TLA+, Z3, and others and how it's significantly easier to map those formal models to our production program code back-and-forth (when written in more expressive and formal-friendly languages like Haskell, etc) than it was 20+ years ago.
Back then the sheer effort involved to perform even automated unit testing and integration testing of VB6 code, and other languages of a similar nature, was massive because, not least, the VB6 tooling completely lacked that functionality, and their lack of terse expressivity meant time spent just writing repetitive code with little value - and things were tenfold worse if you were using one of the myriad proprietary other 4GL languages of the time because most of those vendors swore-off any kind of interoperability or extension mechanism because they saw them as a threat to their business model (as a textbook example see Progress' utterly laughable defense of maintaining their position here: https://www.progress.com/tutorials/odbc/open-source-database despite their market-share shrinking and the company quickly pivoting away from their own database system and onto being a generic component/tooling vendor).
Even so, I'm not being ageist: VB6 wasn't state-of-the-art when it came out: Java is older and far better in that regard (VB6's type system is very anemic). I was singling out VB6 for criticism specifically because even back then it wasn't very good, it's just disappointing that so many people used it as the basis for production systems.
[1] Whenever UK friends and relatives refer to me as "working in IT in the 'states" I outright deny it: I really don't feel that I work in "IT".
I’m not a Progress user. Instead I get paid lots of money to help companies move-away from Progress to Postgres :)
(Which in practice just means figuring out how to get their bloody “SQL Broker” processes running then dumping everything over ODBC. In order to circumvent the arbitrary and unfair “Users/Connections” licensing restrictions I reversed Progress’ super-seeekrit program code to figure out how their license keys worked and made my own keygen in a weekend, that was fun - I got paid to do that too!). The fact it’s possible to slam out software within a few days while drunk-and/or-stoned (I don’t remember, lol) that undoes Progress’ entire business-model built-around vendor lock-in shows what a house-of-cards they’ve built for themselves.
I wasn't comparing them directly like that.
My point is that in the 1990s if you used VB in production systems then you would effectively be forced into investing a lot of company resources - and mental effort - into all kinds of entirely disconnected approaches for formalising, proving and even testing your system. Whereas the state of the art for formalising SWE work today currently lies in tools like TLA+, Z3, and others and how it's significantly easier to map those formal models to our production program code back-and-forth (when written in more expressive and formal-friendly languages like Haskell, etc) than it was 20+ years ago.
Back then the sheer effort involved to perform even automated unit testing and integration testing of VB6 code, and other languages of a similar nature, was massive because, not least, the VB6 tooling completely lacked that functionality, and their lack of terse expressivity meant time spent just writing repetitive code with little value - and things were tenfold worse if you were using one of the myriad proprietary other 4GL languages of the time because most of those vendors swore-off any kind of interoperability or extension mechanism because they saw them as a threat to their business model (as a textbook example see Progress' utterly laughable defense of maintaining their position here: https://www.progress.com/tutorials/odbc/open-source-database despite their market-share shrinking and the company quickly pivoting away from their own database system and onto being a generic component/tooling vendor).
Even so, I'm not being ageist: VB6 wasn't state-of-the-art when it came out: Java is older and far better in that regard (VB6's type system is very anemic). I was singling out VB6 for criticism specifically because even back then it wasn't very good, it's just disappointing that so many people used it as the basis for production systems.
[1] Whenever UK friends and relatives refer to me as "working in IT in the 'states" I outright deny it: I really don't feel that I work in "IT".