Now I don’t know if my childhood evaluation was correct but I do wonder:
Were there many complex programs written in BASIC? Or was it largely a teaching tool?
The dialect was one of many called "Business BASIC", which basically extended normal BASIC with COBOL-like capabilities like better string handling, decimal math for currency handling, and ISAM-like file manipulation. It allowed for developing the same kinds of applications as COBOL while having a nicer development environment than COBOL.
The major accounting suites for small business of the 1970s, MAS 90 and MAS 200, were written in Basic Four BASIC. A lot of applications were. Other dialects, like Pick BASIC, supported business applications as well. All of these were much more fully featured than like Microsoft BASIC on Commodore/Apple/Tandy machines. Those were toys in comparison to minicomputer BASICs.
Basic Four itself shipped on some microcomputers like the Tandy 2000. Compatible environments came out for PC, including AB86 for DOS, Thoroughbred/OS, BASIS BBj, and ProvideX. Keeping those old systems running on newer hardware was an enticing business, just like for COBOL programs.
Was it a "toy" language? Sure. I once implemented a non-scrolling toy spreadsheet program with it - just a fixed grid of cells - with some simple formula capacity and a manual "recalculate" trigger. Was that educational? You bet. Was it sophisticated? Not really.
But I'll bet there were absolute tons of one-off business applications written in it. A simpler version of what Excel was used for later, and still is. And scientific calculations? If Fortran could do it, BASIC could. Until something better came along to replace both.
People who weren't old enough to be in business remember BASIC as something from their home computers, but BASIC was integral to many businesses in the early years of general purpose computing.
There were plenty of business programs written in BASIC, and part of its appeal was that any business owner with a little time could learn how to customize those programs to suit their particular business' needs.
BASIC wasn't just for homes and home computers. Virtually every computer or computing device produced in that era had BASIC available for it, and for good reason. It was quick to learn, versatile, and when you knew the basics on one system, you could use that knowledge on other systems.
BASIC was available on machines ranging from $250 to $200,000 or more. There wouldn't be BASIC on $50,000 machines if there wasn't a demand for it.
My memory is a bit fuzzy on this specific, but I'm pretty sure that HP had a computer that came with both BASIC and AP/L. Nobody was using that machine in their homes.
I was a big fan of BASIC when I was young, and that led to spending the early portion of my career working on a series of BASIC compilers, all of them intended for complex software development. Two of them still sort of exist, in much-mutated form; one is now called "Xojo", and the other is Microsoft's rather-better-known Visual Basic.
I started writing a spreadsheet in BASIC, but never finished. I wrote a couple of simple games in it also.
There are more, but I've forgotten about them.
Now, if we expand the definition to include VisualBASIC, then the amount of production software written in the language explodes into at least 100,000 programs.
I don't know generally, but I worked in housekeeping at a large hotel for a few years in my younger days, and the software they used to track the rooms was in interpreted BASIC.
I didn't know that until my manager started cursing because the software broke. When I looked at the screen, the error message syntax was clearly that of BASIC. I just typed "RUN" at the prompt and everything worked again. She thought I was a genius.
Akalabeth was entirely BASIC, but that's somewhat less impressive.
Atari BASIC stored its programs in memory using a tokenized format - it did syntax checking when the line was typed in, and then the tokenized form was stored to save memory. There was a table of variable names, indexed by token. So a quick and easy obfuscation technique was to overwrite the variable names with something like just carriage returns, so that when you LISTed the program it had no variable names and lots of extra line breaks.
As I recall, at least. Haven't reinforced those memories in a while.
I'm very not sure, so I'm guessing that the system had several hundred thousand LOC.
The idea was to stop spending a fortune on mainframe time and run pensions valuations on a microcomputer.
The Fortran system, running on a mainframe, might take 60s to run a valuation.
The same valuation would take a full day to run on a microprocessor, but it worth it because it reduced costs by a lot.
If you mean the actual accomplishment of it in general:
1. Get a subset of data that lets you create a representative set of test cases. You can validate your code in minutes, not hours or days. Then you run it on the full thing once you've seen that the 5-minute job works as expected.
2. Sacrifice a goat, pray to hopefully the right god, and hope it wasn't their son from a goat mother that you sacrificed.
3. Spend a lot more time thinking before doing.
4. Read a lot.
(1) works if you can run the task on your own system or have access to a system to run it on. This is the best option, or some variation on it.
(2) is unfortunately what happens a lot, they usually sacrifice the wrong goat and end up cursed instead of blessed.
(3) and (4) are the next best option after (1), and should be done alongside (1) anyways. The system I'm on now is legacy and being upgraded. The test bed is available to me maybe 1 hour a week right now because everyone needs it and everything is urgent, apparently. I spent a lot of time reading the code, the documentation, and thinking about how to structure my solution to a problem our users have. My first pass validated the solution concept and took 3 days or so of thinking hard about the problem and 5 minutes of coding. The second pass is more robust (error handling) that took several more days of reading and thinking to identify what error cases could even occur, and two hours of coding.
Yeah, if I could run it locally I probably could have finished it all in those first 3 days (honestly my 5 minutes of coding was figured out by the end of day 1, but I wasn't certain since I was new to the codebase). But when that's not an option, you spend more time thinking about the problem you're solving and the problems your solution will generate so you solve it before you run it in the first place.
Was much commercial software written in BASIC? (Edit, because this is being misunderstood: I'm not talking about the evolved BASICs being pushed by the late 80's, only about the ones like Applesoft and GWBASIC the commenter is asking about) No, very little. As you point out BASIC doesn't offer much to developers who already understand a macro assembler. But the market was much bigger than that.
https://en.wikipedia.org/wiki/Business_Basic
Was popular with some smaller companies for their internal custom systems. Had some similar capabilities as COBOL without the IBM tax.
COBOL never had an "IBM tax", because almost every non-IBM vendor had a COBOL compiler. If you didn't want your COBOL from IBM, you could buy it from DEC, HP, Wang, Unisys, NCR, Honeywell, Microsoft, Micro Focus, Watcom...
That said, if your COBOL was running on an IBM platform, you often were using lots of IBM proprietary features (e.g. CICS) which made it hard to port to another vendor–and that could indeed be an "IBM tax". But that's wasn't due to COBOL in itself. If you limited yourself to standard COBOL, and avoided IBM proprietary stuff, moving your COBOL app to another vendor didn't have to be difficult
BASIC attracted business users because it was viewed as simpler and easier to learn, because it could run on smaller machines, because (often) using an interpreter instead of compiler resulted in faster development (no edit-compile cycle).
https://www.wherry.com/gadgets/retrocomputing/vax-simh.html
Modern GNU COBOL can be found at this site:
https://www.gnu.org/software/gnucobol/
A great deal of the COBOL that we use relies on OS2200 DMS, originally from Univac.
Where? I don't see any VMS 1.0 image linked to on that page.
Instead I see instructions to join the HP OpenVMS hobbyist program, which no longer exists, in order to install OpenVMS 7.3 on an emulated MicroVAX.
There is no longer any hobbyist program offering legal access to VMS for VAX. HP's hobbyist program was terminated and replaced by VSI's, which never included VAX (and more recently they appear to have dropped Alpha and Itanium, making it x86 only). Licenses to legally run VMS for VAX are very limited (e.g. maybe buy a used MicroVAX or VAXstation which comes with a VMS license)
I have downloaded all of this and run it on a rhel9 clone.
There was a huge amount of commercial software written in BASIC dialects such as classic Visual Basic and ASP, Pick/BASIC, HP Business Basic, Wang 2200 Basic, DEC BASIC-PLUS, etc. Boring business software you would likely have never heard of but which was (and in some cases still is) essential to running all kinds of different businesses.
I used to work for a university and both the student administration system and the accounting system were off-the-shelf software, mostly written in VB6 and classic ASP (I believe the vendor also had some COM components written in C++, they had their own app framework, but the business logic was all VB6). At the time, we were waiting for the vendor to finish porting it to VB.NET. 20 years later, it probably still is in VB.NET.
They weren't. Many minicomputer BASICs of the 1970s and early 1980s, such as Wang's, lacked those structured programming features you are talking about, at least originally. They were classic GOTO/GOSUB line number spaghetti code. And huge amounts of business software was written in them.
Some of those apps still run today, because the languages have been ported to Windows/Linux/etc. And eventually, just like Microsoft did, they added a lot of those structured programming features. But sometimes you'll find pre-structured spaghetti-style code surviving long after the dialect gained the ability to do better.
The outfit I worked for at the time sold directly into this area. We had a product line of simple I/O modules for physical automation (measuring temperatures, controlling motors, etc...) and all our programming instructions and examples were given in BASIC because it was on all computers and it was the one language that we knew everyone would be familiar with.
In the '90s when we were developing a 3D game (in C++) I made an early iteration of the level designer in VBA on Excel. You would color cells in a spreadsheet and then hit a button, and the button would output a text file that told the game engine what mesh or object to put where. Terrible way to do it, but a great way to work fast in those primitive days.
I still have nightmares about having to write the Validation procedure documents for a medical device production Quality system written in VBA/Excel. The program had started out as some scientist's desktop tool and somehow over the years, morphed into an actual production tool that now needed to be formally validated since we needed to make a change to it. Worst combination of spaghetti code and Big Ball of Mud that I've ever seen. I had the misfortune of being the only SW dev who was senior enough to do the task and who wasn't busy at the time, so I drew short straw!
I shudder to think of the millions of dollars of product that have been shipped as a result of that code!
One that I was interacted with was a CAD software written in QBasic. It was about civil engineering and static analysis tool for concrete buildings. You could export projects to dxf format so you could import into AutoCad to fix bugs and plot.
Funny how the name was MGCad and author insisted it stood for MegaCad. I suppose It was a nice coincidence that the Author's initials were MG :)
Lots and lots of 'business middleware' was written in various forms of BASIC, the most famous being VBA, but also quite a bit in things like QuickBASIC in an older period.
https://qb64.com keeps the dream alive.