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.
> 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.
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 was shown some ProvideX code written by a Sage MAS 200 "partner / reseller" for a custom vertical version of MAS 200 to review for a Customer. The code was a horrifying maze of numbered lines, GOTOs, and global variables. It reminded me of the Applesoft BASIC stuff I wrote when I was 8-10 years old... except this code was handling hundreds of millions of dollars of revenue. Yikes!
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).
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.