Prior to 1985: (As a child.)
I wrote "snake" and independently came up with the circular queue data structure. I wrote a "Bezerk" clone in low-res graphics, where everything was just a dot. (I had no idea how I could handle the AI at the time, so baddies just moved randomly.) I wrote a "skiing" game that exploited text scrolling for the vertical scrolling. I wrote a "Star Wars" game where you tried to "fly" a ship with a joystick first person to line up Tie Fighters in the crosshairs. It was a clone of one of the demo games which came with the Apple II, but mine had a "horizon." I wrote the start of an Asteroids style game, where I got a swarm of 50 ships to chase each other around in a massive "dogfight." All of the above was done with BASIC, except for the last, which was done in a BASIC derived macro language called Macrosoft.
More recently, a few years back I taught a class for high school aged women, where we used Unity 4 to create a 2D shoot-em-up game in just one afternoon. 18 of the 19 students rated the class highly. Granted, we had to "pre-fab" a lot of things for the students to keep things moving. The actual point of the course was to give the students a taste of what they could do.
It's not the result that's interesting, it's the process of programming.
Some years back, back before Arduino was even a thing, a friend of mine (who looks a bit like a cross between the stereotypical 50's geek and Kyle Maclaughlan) and I spent an entire evening bringing an embedded computer to life. We got an LED to blink then awkardly high fived. His wife just shook her head.
The stuff I was able to do in Basic in 1981 as a ten year old kept me interested. Then like now I enjoy programming, but mostly as a means to an end. If anything, the fact that what I could program wasn’t as “interesting” as a commercial game (say) was motivation to keep learning.
That's just not true. For I/O you had keyboard input, screen output, and maybe file I/O. 3 basic things that pretty much all programs used. Most commercial programs were 80x25 text mode with 16 color attributes. If you could learn to read scancodes from the keyboard, write text to the screen, and save/load files, (along with a few fundamental ideas like loops and conditionals) you could do almost anything that a commercial program did. With just that basic knowledge of a few simple things.
It was simple because it was direct, there weren't 72 layers of abstraction and UI libraries that you had to know before you could even begin. You could also do pixel graphics, and again it was pretty simple - just set the screen mode and go with DRAW, LINE, CIRCLE, POKE etc. Again, no layers of indirection or libraries or window managers or canvases or DrawableObjectFactoryManagerFactoryInterfaces needed.
One of the problems of modern attempts to recreate that feel is just that there is so much between the programmer and the hardware and it's so much more complex. Back then, we had single-user, single-process systems with direct access to simple hardware. Everything you needed to do was either a built-in part of the language or a BIOS/OS interrupt that you could call just as easily. It's hard to recreate that on a multi-user multitasking system with indirect access to more complicated hardware and countless layers of software between the programmer and the machine and BIOS/OS interrupts. Sure you can do more powerful stuff now, but it's not as interesting.
Just personal observations here. Someone with a computer in 2019 can download Unity, which is free, and watch a tutorial on YouTube, which is also free. With near zero understanding of what is going on, and no prior experience, they can have some kind of rudimentary platformer working within hours. This is then a good starting point to learn programming (you can dive into C#) or you can continue to jumble together copy/pasted bits of code that you see online (kind of like how I remember doing with BASIC and library books).
Sure, there are a bunch of layers of abstraction, and those abstractions will break down all the time. You don't need to learn those abstraction layers, you can stay at the top layer and still get good work done, maybe working around a few problems that you don't understand from time to time by futzing around with stuff until it works. Or you can dive in and try to understand what's underneath an abstraction. That's the whole point of having abstractions in the first place. They exist to hide the complexity, to let you get work done without understanding the entire system. 72 layers of abstraction is a bit of an exaggeration. I'd say if BASIC has three layers (interpreter/machine code/hardware), Unity only has six (editor/scripts/engine/os/machine code/hardware), but who knows how you count them.
In my experience, watching people learn how to create things, it has never been easier to learn programming and start building things. The main difference is that in 1985, programming was considered an essential computer skill, and in 2019, you're expected not to program. BASIC was amazing because it was what you saw on the screen when you turned your computer on, nothing more.
Sure, when I wanted to make games I moved to C++ and Perl for web apps, but without programming experience those languages looked like a mass of symbols while BASIC looked like sentences.
For an entry level language it was perfect for me.
We used to write goofy games, share them, hack on all of it, and had lots of fun. Imagination.
Now, the blue dot is the baddie, and you....
See if you can find the GDC presentation they gave. It was the most entertaining presentation of that year I can remember.
Back then, as a child, my parents purchased books that contained basic programs that one could manually transcribe and save onto tape or disk that were actually interesting. IIRC, those books did contain an overview of how the program worked.
It's not the result that's interesting, it's the process of programming.