3 ms·

> Thankfully Why? If it works...

by ghssds 1y ago

romanhn 1y ago
End of life software running on top of end of life software. Hard to hire for this stack, especially anyone who cares about tech. Security and maintenance nightmare. Interoperability is a pain. Questionable documentation. It all works until it doesn't, and then you're in the world of pain.
- jackvalentine 1y ago
  A client of mine used Visual Foxpro for… way past its used by date, for a crucial database in a crucial aspect of a crucial industry. When it inevitably failed spectacularly they struggled to get anyone who knew what was up to intervene. Same client kept poor backups. Recently persuaded said client looking for a new solution to support a new line of business to go with the .NET, actively developed system over the ‘free’ VB6 desktop application that a charity developed a billion years ago and wanders around the industry inflicting pain.
- potoooooooo 1y ago
  Not all of these issues apply to VBA, which the top level comment brought up,even if they apply to VB6 and the other ones you mentioned. VBA isn't EOL, and Excel certainly isn't. Lots of people are continually building sophisticated tools in MS Office even though it's not helpful for the resume because it's the path of least resistance for solving problems for the sorts of people who just learned VLOOKUP in 2021 and don't want to learn about XLOOKUP now. Security, maintenance, interop, documentation... There are arguments to be made. It's not cut and dry that VBA is the worst option for any of those. The patterns for handling them are different than a web app repo or something, but it's not like they don't get thought of and handled on a daily basis.
anthk 1y ago
Active X it's a security disaster.
- int_19h 1y ago
  Only in the context of embeddable web components, and only because running non-sandboxed native code in the browser is a security disaster in general, not because of anything specific to ActiveX. Outside of that context, ActiveX is simply a well-defined object-oriented API and ABI for cross-language use.
  - anthk 1y ago
    It wasn't any better for Windows 98 with IE bundled in the shell, and audio parsing functions right in the kernel. Up to the point tons of people chose to revert W98's shell to the Win95 one, having a good speed boost on some PI-PII machnes. VB6 was a good idea as a RAD tool; but, as TCL 7.x (and the older 8.x releases), the performance wasn't fast enough until some Pentium 3/Pentium 4 for 'big' software. Not an issue for a boring company program or the 234000000nth shareware crossword puzzle software for PC magazines or sites as Softonic. Or some whatever catalog hooking up some Excel/Access libraries, or nice in-sormware forms borrowed from IE DLL to create zillions of similar shovelware. That kind of niche software was everywhere. Ditto with some simple games written in VB; but the native ones outperformed VB ones with ease. And, yes, you could call native DDL's, but most amateur programmers didn't do that.
    - int_19h 1y ago
      "Boring company program" is exactly what VB was made for. People tried to use it for other purposes because when you have a hammer, you make everything look like a nail, but I don't recall any actual prominent software written in VB outside of line-of-business stuff. "Serious business" in that timeframe was done either in Delphi or in C++.

> Thankfully Why? If it works...

by ghssds 1y ago

> Thankfully Why? If it works...

End of life software running on top of end of life software. Hard to hire for this stack, especially anyone who cares about tech. Security and maintenance nightmare. Interoperability is a pain. Questionable documentation. It all works until it doesn't, and then you're in the world of pain.

jackvalentine 1y ago
A client of mine used Visual Foxpro for… way past its used by date, for a crucial database in a crucial aspect of a crucial industry. When it inevitably failed spectacularly they struggled to get anyone who knew what was up to intervene. Same client kept poor backups. Recently persuaded said client looking for a new solution to support a new line of business to go with the .NET, actively developed system over the ‘free’ VB6 desktop application that a charity developed a billion years ago and wanders around the industry inflicting pain.
potoooooooo 1y ago
Not all of these issues apply to VBA, which the top level comment brought up,even if they apply to VB6 and the other ones you mentioned. VBA isn't EOL, and Excel certainly isn't. Lots of people are continually building sophisticated tools in MS Office even though it's not helpful for the resume because it's the path of least resistance for solving problems for the sorts of people who just learned VLOOKUP in 2021 and don't want to learn about XLOOKUP now. Security, maintenance, interop, documentation... There are arguments to be made. It's not cut and dry that VBA is the worst option for any of those. The patterns for handling them are different than a web app repo or something, but it's not like they don't get thought of and handled on a daily basis.

anthk 1y ago

Active X it's a security disaster.

int_19h 1y ago
Only in the context of embeddable web components, and only because running non-sandboxed native code in the browser is a security disaster in general, not because of anything specific to ActiveX. Outside of that context, ActiveX is simply a well-defined object-oriented API and ABI for cross-language use.
- anthk 1y ago
  It wasn't any better for Windows 98 with IE bundled in the shell, and audio parsing functions right in the kernel. Up to the point tons of people chose to revert W98's shell to the Win95 one, having a good speed boost on some PI-PII machnes. VB6 was a good idea as a RAD tool; but, as TCL 7.x (and the older 8.x releases), the performance wasn't fast enough until some Pentium 3/Pentium 4 for 'big' software. Not an issue for a boring company program or the 234000000nth shareware crossword puzzle software for PC magazines or sites as Softonic. Or some whatever catalog hooking up some Excel/Access libraries, or nice in-sormware forms borrowed from IE DLL to create zillions of similar shovelware. That kind of niche software was everywhere. Ditto with some simple games written in VB; but the native ones outperformed VB ones with ease. And, yes, you could call native DDL's, but most amateur programmers didn't do that.
  - int_19h 1y ago
    "Boring company program" is exactly what VB was made for. People tried to use it for other purposes because when you have a hammer, you make everything look like a nail, but I don't recall any actual prominent software written in VB outside of line-of-business stuff. "Serious business" in that timeframe was done either in Delphi or in C++.