Sure. Before the Altair/MITS/SWTPC/Kim/Sinclair/Pet/RadioScrap/OSI/Apple things happened, there was a delightful little machine known as the IBM 5100. It had BASIC in ROM, a big cassette tape drive (or two), 8 KB of memory. a 24 line screen, and a printer, all for a measly USD 10,000 -- an order of magnitude cheaper than your typical mini. Originally built for scientists (APL in ROM was also an option), but then a few accounting types discovered it, and started a craze: every small business wanted one. With custom software, of course. The 5110 followed that, with the tape drives replaced by 8" floppies.
Any commercial software? Galoons.
Can you say general ledger, payroll, accounts payable, accounts receivable, inventory control, and invoicing? I have been there, done that -- in BASIC. Utility bills, new and used car inventory, garbage truck pickup and beverage delivery scheduling? Yup -- BASIC. Want to track iron ore from mines onto trains onto ships... BASIC. Everything that wasn't raised floor was likely getting done in BASIC. Commercially, I mean. (Because RPG II doesn't count ;-).
How did one work around the limitations?
Well, the first thing you did was send the customer back to IBM for more memory, Because who could write anything serious in 8 KB? You simply had to have 16. And two tape drives, if possible, because automata theory aside, merge sorting on a single tape is, well, a tad slow.
Oh, sorry - you meant the limitations of BASIC.
Well, you had to manage your resources pretty carefully -- things like line numbers -- because you didn't want to run out of those; real pain in the behind to have to renumber a whole section, and type it all back in, without accidentally losing a line or two of code.
Nah - just kidding. We didn't actually have that problem until micro---er, home computers showed up, with a BASIC interpreter that couldn't do renumbering by itself.
We also used modularity - where you called a new program, ran it till it quit and returned back to the calling program. A gosub on steroids (because you got more memory to use), but way slower (because it took a while for the machine to find the program on the tape, and load it in, and then rewind and find the original program and load that back...). A lot like a fork and exec, but without the fork, only better because the whole memory space was shared.
Rigorous use of conventions also helped -- you know, like "you MUST always target a GOSUB at a comment line that says what this routine does, and you SHOULD do the same for a GOTO when possible. Stuff like that. Oh, and structured programming, a little later -- "by convention" again.
Some even went a little to the extreme: OAOO, YAGNI, TSTTCPW, pairing, refactor mercilessly, that sort of stuff. Not by those names, of course. (See also: Ecclesiastes ;-)
The glory days.
It's running 2.5 million lines of C on a RAD750 processor manufactured by BAE. The JPL has a bit more information but I do suspect many of the details are not publicized. It does appear that the testing scripts were written in Python.
The underlying operating system is Wind River's VxWorks RTOS. The RTOS in question can be programmed in C, C++, Ada or Java. However, only C and C++ are standard to the OS, Ada and Java are supported by extensions. Wind River supplies a tremendous amount of detail as to the hows and whys of VxWorks.
The underlying chipset is almost absurdly robust. Its specs may not seem like much at first but it is allowed to have one and only one "bluescreen" every 15 years. Bear in mind, this is under bombardment from radiation that would kill a human many times over. In space, robustness wins out over speed. Of course, robustness like that comes at a cost. In this case, it's a cool $200,000 to $500,000.
An Erlang programmer talks about the features of the computers and codebase on Curiosity.
Best Answer
There's a book in Russian, German Noskin, First computers (literally board digital computing machines) for space applications (Герман Носкин, Первые БЦВМ космического применения), ISBN 978-5-91918-093-7.
The author himself participated in many early projects (mostly in hardware) and according to him analog hardware was in favor for a long time, he mentions that space rendezvous tasks didn't use digital computers until the late 70's. Due to this policy many digital computers were really proofs of concept although used in other areas of soviet economics. The first computer according to him used on-board was the Argon-11S (Аргон-11С) on the unmanned missions to the Moon closer to Apollo-8 in time. Also Noskin briefly says that the on-board computer Salut-4 was compatible with general-purpose computers ES used in Soviet economics so it was possible to develop software in PL-1 and Fortran.
There are several mentions of Buran program languages on Russian websites. According to Vladimir Parondjanov, an engineer from the program (Russian Post) three languages using Russian as a base were developed: PROL2 (ПРОЛ2) for onboard programs, Dipol (Диполь) for earth tests, and Laks (Лакс) for modelling. All of them were intended for use not only by professional programmers but also engineers from other areas.
When the Buran program was closed they were merged into a new language Drakon (Дракон, Russian word for "Dragon") that is claimed to be be a "graphical" language having 2-dimensional descriptions of the programs and using arbitrary well-known languages for code generation. This language was also intended for use by non-programmers. The language probably does not have and international community and isn't even well-known within Russia although heavily promoted by its author, Vladimir Parondjanov (the Russian Wikipedia article article is very long and was even deleted once for not following Wikipedia rules). Drakon was first used for programming for the Sea Launch missions and has been used in other Russian space programs since.