But still, I learnt a lot by modding basic games I typed in from books, then later learnt a lot of assembly as I tried to mod those assembly language programs I typed in with hex codes. You'd print the whole program out using a good ol dotmatix printer ( took a while.... not because there was that much code, just printers were slow... ) and then puzzle over the assembly trying to work it all out and drawing lines trying to work out all the jump sequences etc. Later my Dad and I had a lot of fun hacking tape based games so we could put them on our awesomely huge (doubly huge if you cut a notch and flipped them over) and speedy 5/14 inch discs.
That varies a bit by platform. Most 8-bit machines had relatively poor BASICs and no assembler, so BASIC code could be a mess of line-number targeted GOTO/GOSUB statements and anything that needed to be faster than the higher-level language interpreter could manage needed to be pre-assembled and just pushed into the relevant RAM locations by a BASIC loop as you describe.
I had the luxury of learning on Acorn machines, initially an Electron then a BBC Master Series. Their variant of basic had useful features which implementations on other 8-bit devices lacked: long variable names (IIRC the C64's BASIC allowed long names but only used the first to characters so PersonName and PermitCount would clobber each other, BBC basic respected up to 40 characters of a name), named procedures and functions, and a built-in multi-pass assembler. This made BASIC code (if written using those features obviously, some magazines had content targeted at multiple architectures and stuck to the lowest common feature-set) easier to read, understand, and modify, and made it possible to see any machine code logic so you had a hope of pulling it apart usefully too. I learned a lot starting from nuggets in type-in demos and using them as starting points to experiment/read a little deeper, not just about those specific machines but reading around computer architecture more generally. I don't think I'd have the same level of competence or knowledge that I have now were it not for that start.
On the Beeb most listings were BASIC with all the logic there and DATA statements just for in-game assets such as sprites or room descriptions in a text adventure. All the Osbourne books are online now , check them out https://www.raspberrypi-spy.co.uk/2016/02/usborne-releases-1... many happy memories inside!
Most of the assembly and other DATA/POKE stuff is less than relevant nowadays as hardware has improved and a lot of magic is already done in firmware.
The form of "type it in, verify and run; explain mistakes and correct solution" is still didactically valid.
I'm pretty sure there are programming language interpreters out there with simplicity of BASIC, including BASIC itself.
On MS-DOS, you had a variety of commands built in and extensibility via BASIC too. (or more) Programs could be written as batch files. On Unix-like, the primary interface was via shell, csh, ksh or later POSIX. A set of built in commands. If you wanted something more advanced, programming languages and interpreters were easily available, typically pre-installed.
It was the main interface, magic words. We have regressed to pictures now and most extensibility has been hidden, removed and made very indirect.
Hardware doesn't come with programming manuals anymore as it is deemed too complex (yeah right) and expensive. It is be great if your GPU came with a description and software to write and execute shaders, for example. PC with instructions how to programmatically reboot it, start it or access sensors. How to access EFI services. What the machine code looks like. Etc.
It doesn't come with manuals because it is considered a trade secret. Commodore had to lay the hardware bare because it wasn't fast enough to program in a high level language nor did the high level languages fully support their hardware, whereas the hardware of today is so fast that nobody thinks anything of it programming it through a driver or a shared object library in a high level language. It's still wrong not to lay the hardware registers and their functionality bare (yes NVIDIA, have you forgotten your SGI roots?)
It takes time to produce useful documentation though.
I've read a discussion in a forum where an AMD employee when questioned if it was possible to have a GPU's FW without DRM (or something like that) his answer was that would probably be a commercial suicide (OK, I'm little tired right now and I'm not recalling all the details of the conversation but I can try to dig it up... ^__^;)
25 years later I bought the real thing.
The code was out in the open and decipherable. Great way to learn in that particular environment.
Atari with their player-missile graphics made immediate sense to me though.
One of the things that mentor emphasized was writing a dissassembler soon after becoming familiar with a given CPU.
However, that woild be post fact. Some teens got closed computers, like Atari machines. By todays standards, they are wide open. Back then, they were mysterious, but capable with spiffy graphics and sound chips. The key thing was how users were nudged toward or away from the guts of it all.
Other teens got, say an Apple 2. On that one, you got schematics, a commented ROM listing, and the whole machine was open, software driven. It screamed, "hack me!" The whole damn computer was a clever hack!
Again, my per group were Apple people, and were writing ML based off the snippets found in the ROM, along with great tutorials found in the grocery store magazines. (Where I got my first dissassembler, BTW. Thank you COMPUTE!)
This stuff varied extremely widely. One town would have that spark of learning, a particular school, or club maybe. Another one, nothing. Just gaming, the usual.
Circling back, yeah. Those DATA statements were known to be programs. Lots of us hand disassembled them and either wrote them down (I have a couple in some papers somewhere, I am sure), and my preference was to add REM statements with assembly code in them for later. Oh how I would have loved BBC Basic!
The Apple was cool, had a monitor and mini assembler, disassembler. Wrote a lot with it. Still a mess compared to what I understand the BBC had. I want to go and run one.
Other machines varied, as did people and what books and or other resources were available to them.
However, because I was young and still had memory in my brain, by typing in those poke data parts, patterns stuck in my memory. When I bought my first asm book, I finally understood what those patterns of opcodes meant. I never programmed in assembly instructions on the z80; I always used direct opcodes, still do. It is faster for me.
The more advanced I had found was a football (soccer) simulator that was working like a text adventure game, showing you the development of the game by writing the words of the sportcaster in regular time intervals. Being able to understand it and modify it, was a milestone on my growth as future programmer.
Anyway, I learned a few things from those listings early on.
As someone who was there and did that I want to refute that assumption :) I have typed in many programs and there's not a lot to learn because most of them consisted of many pages of DATA lines and a small loop that loaded those machine instructions into the home computer's memory and started the program by a USR directive (please note that I made this explanation many years after the fact). I guess there are not many teenagers who are able to debug this kind of program by looking at the actual opcodes.
Sure you could learn a lot from typing in regular BASIC programs but that weren't the most interesting games as far as I remember. The most productive learning experience was interactive and exploratory programming a shown in the OP article.