Looks like these are both "business" BASIC variants. Wiki has some information about ProvideX, nothing about BASIS (either the company or the BASIC product). What's the point of coding in these sorts of languages at the dawn of the 2020s? Do you still have a lot of legacy code around that can't be forward-ported for some reason? Do you have non-technical folks surveying the code, or even contributing to it?
Both BASIS and ProvideX are based on Java and provide rather thorough JVM integration. The languages themselves also haven't remained stagnant; they have approximate feature parity with Visual Basic. Both are derived from the MAI Basic Four dialect that was popular in the 1970s.
And yes, some large complicated business software, including the MAS 90 and MAS 200 accounting systems, was built using Basic Four. Porting such a complicated code base would be cost-prohibitive compared to porting the Basic Four dialect of Business BASIC to new environments and just running it as is -- so Business BASIC is COBOL-like in that regard also.
I'm aware of this evolution. However, the software at my company was not maintained to keep pace with it. Instead it was endlessly customized within the constraints of the original interpreter. At this point, updating the software to use newer variants even by the same companies would take roughly the same effort as rewriting it in Python, for far less reward.
The first piece of software I ever wrote and sold commercially was in Business BASIC. It was what we would call a CRM these days, though massively scaled down compared with what we have today. I did it for a limousine company. This was around 1982, IIRC.
Outside of the SV bubble, it's not common for companies to migrate working systems to something new unless the benefits clearly outweigh the costs, and there's nothing better on which those those costs could be spent.
There are a number of stories online, in HN, and in the business press where companies "upgraded" from legacy systems to something "saner" and it ended up costing more time, money, and customers than it was worth.
ProvideX sounds like it's now Sage Group's ERP extension/plugin language. Like SAP's ABAP, Microsoft's "AL", etc.
Relying on line numbers, GOTO, GOSUB and RUN/CALL for flow control, all variables are global. This makes it extremely difficult to reason about code and make changes without breaking anything. A modern language would have functions, objects and modules with descriptive names, scoping, and, you know, white space. OH, and it would be stored in a normal text file; the source code for these BASIC interpreters is stored in a binary tokenized format, which makes it difficult or impossible to use version control systems like Git. (I do have something jury-rigged in place for this but it's very ugly.)
Additionally the data is stored in flat files. So a "record" (in this system at least) is basically a really long string with the fields stored in specific places in that string. If you need to change the data structure you have to update the hardcoded substring references in every single program that accesses the file. (Often you are better off defining a new file and cross-referencing it with the others.) There is no relational aspect; what would be a two-line SQL query becomes 40-100 lines of BASIC code where you zip through the whole file record by record, often involving building an intermediate temporary sort file and then zipping through that.
In essence: BASIC, especially this older flavor, is such a "simple" language that using it for anything non-trivial is little better than writing in assembler.
In some BASIC implementations, it was quite possible to 'LOAD' and 'SAVE' programs as plain ASCII text by adding the appropriate incantations somewhere, even though the default representation was tokenized. I'm not sure if the "Business" BASICs you're using can do this.
> Relying on line numbers, GOTO, GOSUB and RUN/CALL for flow control, all variables are global. This makes it extremely difficult to reason about code and make changes without breaking anything.
Well, I'd say less "difficult", and more like "impossible absent a tedious reverse engineering effort". Figure out all the jump targets and all the subroutines, and document the globals that each relies on/modifies. Then you can treat your subroutines as something a bit closer to plain functions. (They'll still be non-reentrant however. Meaning that subroutines cannot recurse in general, not even indirectly.)
> So a "record" (in this system at least) is basically a really long string with the fields stored in specific places in that string. If you need to change the data structure you have to update the hardcoded substring references in every single program that accesses the file.
The really old BASICs had their own notion of "record"-based file that was essentially the only kind of file that could be randomly accessed. "Sequential" files were entirely separate and only supported appending, absent language extensions.
I ended up researching ProvideX pretty heavily as part of that work. The language was evolved from its original roots (much like Microsoft QuickBASIC / PDS evolved out of GWBASIC). Just like QuickBASIC, thought, it could still run the old line-numbered, globally-scoped, nightmare spaghetti code too. There were some neat constructs to deal with ODBC, GUI controls, etc, to be sure, but it seems like it exists now only to serve the old, rickety codebases that are in that "milk the market dry" mode (which pretty much sums up all of Sage's software, too, interestingly enough).
That's a big question. And how much is that ongoing maintenance going to cost you, when you're critically reliant on it? It's just a single point of failure that will ultimately have to be addressed.