Comment by bitwize
1 day ago
Here's something that will bake your noodle. Sage 100, the accounting/ERP software, is still to my knowledge written in Business BASIC from the 1970s—specifically the variant that ran on MAI Basic Four minicomputers (just 64 KiB of RAM!). This variant of BASIC was so, as Claude says, load-bearing that several companies emerged to support source-compatible versions on a variety of platforms as the non-mainframe business world evolved from custom-schmustom minicomputers to Unix workstations and PCs. The most common variants today are BASIS International's BBx and BBj (Java), and ProvideX. Sage 100, originally MAS 90 and MAS 200, was an accounting solution originally developed for those 1970s minicomputers and then forward-ported to new platforms as the business landscape evolved.
I dealt with ProvideX code for a Customer who was using an industry-specific customized version of MAS 90. I managed to see some of the source (under NDA) of the customizations and it was fucking horrifying-- line numbers and GOTOs and global variables. It makes my eyes burn a little thinking about it...
One feature that Business BASIC did have even way back in 1975 that I really appreciate is some form of exception handling: just about every I/O operation had, as a required argument, at least one line number to jump to in case of failure. Some required several, for different types of failures (file not found, I/O error, etc.).
That code you looked at must have been incredibly old! I think that BBj and ProvideX both added structured-programming features to make working in their environments at least somewhat tolerable. As intolerable as we find it today, Business BASIC was really a breath of fresh air in its time compared to the alternatives, like COBOL...
I dug up to code to make sure I was remembering properly and, oh boy, I was! There's a header on the file that indicates a revision date of 2011. I wonder if the coding style isn't based on style-guidelines at the MAS 90 customization company. I'm betting they have code going back decades, and keeping a consistent style is probably a win (even if the style is eye-gougingly bad to read). I do see they've adopted a mix of numeric line numbers and alphanumeric labels.
I'm used to "ON ERR GOTO"-type error handling in BASIC dialects, whereas in this code I'm seeing a lot of defensive "IF ERR=xxx" after API calls. It looks like they're also "cleverly" using the division by zero handler as an "escape hatch" out of a subroutine. To paraphrase some their code:
> 31338 IF ERR=15 THEN LET ERRMSG$=MSG(-1) ELSE IF ERR=14 THEN GOSUB DB_LOGIN; IF NO_CONNECT THEN LET a=1/0 ELSE GOTO 31337
That's the stuff!
Apparently they didn't make use of line renumbering (or the ProvideX environment doesn't support it) because I see features and error-handling shoehorned in between lines numbered ascending by 10. It reminds me of 9 y/o me shoehorning in new code when I was trying to write text adventure games using a unique INPUT / IF/THEN / GOTO block for each "room" of the game.
For anyone who has had to touch any desktop version of Sage in 2026, this is not at all a surprise.