[dvratil]

My dad (who's an architect but learned a little bit of programming on the university in the 80s programming on punch-cards) wrote a few simple QBasic programs with basic math and English vocabulary excercises for me when I started primary school. When I was 13 or so I found them again and ask my dad to explain it to me how it works. He did not remember much, but he showed me a few commands he remembered and that's when my world turned up-side down. I learned everything else myself from the built-in documentation (although I did not understand big portion of what the docs said) and spent almost all my time at the computer, writing stupid small programs in QBasic. The ultimate program I wrote was a silly Windows 95 clone with the Start menu, calculator and clock programs built in. At some point the code was too big that it wasn't possible to run it, because there wasn't enough memory left after QBasic loaded the source code. Worth saying that the computer had 4MB RAM, though, so it was probably just a few thousand LoCs.

From QBasic I went to Delphi, did a detour to PHP/HTML during high school and ended up at C++ some 14 years ago. Today I'm a SSE and I still love programming and everything about computers. Seeing this post (and all the cool stories in the comments) brough a big nostalgia hit - all those hours spent in front of my dad's Compaq Contura just writing one QBasic program after another (and playing Commander Keen, of course!)...there's a big box of flopp disks at my parent's house, I suddenly feel a big urge to go buy a floppy drive and see if any of my masterpieces have survived...

[lproven]

QBasic was a DOS interpreter, so the 4MB of RAM didn't matter. DOS couldn't see more than 640kB of RAM, and I am not sure if QBasic even used all of that.

[BearOso]

Worse, QBasic was limited to one segment of 64k, or what Borland called the "small memory model." If the code and inline data was larger it couldn't run.

Many programs would inline machine code and jump to it to get around limitations like that.

[lproven]

I thought it might be, but I wasn't sure...

Mind you, in my first job, we had a full professional system, written in GWBASIC.

It was 300-400kB of code, in modules of under 64kB each. There was one big module that set up all the variables, then it loaded the other ones in on top of itself. Variables stayed in memory, so there was no need to explicitly pass values between modules.

All very modular, with a big block of REM statements detailing what would be found in memory, under what names, etc.

It was fast, on a PC-XT class machine with a hard disk. It ran on anything, even with no memory management. The runtime was included with DOS, so the company didn't need to include anything extra.

When my employers started out, they were very small and a copy of QuickBASIC would have cost too much.

This app cost many hundreds of pounds in the mid-1980s. By the end it was £200-£300, bespoke customised for every client.

My boss wrote it and really wanted to modernize it. His boss wouldn't let him. In the end, he quit and started his own company.

I quit that job and went to work for my former boss, who rewrote it in QB4, removing all the line numbers and making it one big monolithic structured app, compiled.

But TBH that didn't add any functionality, made on-the-fly patching much harder, and meant it was up against full-fledged professional apps.

(The niche was that I lived on the Isle of Man, which has unique tax laws. British payroll apps are no use; American ones, worse. But expensive pro-grade apps were very customisable and could be made to fit.)

CP/M only handled 64kB of RAM and that needed to fit the OS too. Lots of business software ran in that space.

TL;DR: you can (or could) write useful professional apps in an interpreter with a 64 kB code+data size limit. Big ones, if you're rigorous about modularity.