It's not the result that's interesting, it's the process of programming.
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.
He likes electronics because they have games. Usually the older games are better for him anyway because they are simpler. Right now his favorites are Worms Armageddon (iPad/PC/N64) and San Francisco Rush 2049 (N64).
Since he doesn't have free access to any of these devices, he is perfectly happy to use whatever we allow at the time ("Daddy, can we play games on the TV from when you were a little boy", referring to a 12" junky CRT for the SNES). I have no doubt he would be thrilled to have some kind of retro computer to use QBasic on, just like I did when I was 8.
You wildly underestimate the power of a child's imagination. The problem is free access to overstimulating contemporary technology, not some intrinsic boringness of old software.
You and he should make "San Francisco Rush 2019" where you jump around from startups to FAANG all the while trying to make enough money to keep up with housing price increases.
I feel like that's exactly what the parent comment said.
My kids have always loved retro games too, as well as current games, and they are also interested in programming. But for a decade they've been unable to motivate themselves to actually do the programming. My oldest has asked me to teach him multiple times, and when I help him, it doesn't stick. He doesn't have the patience for code. He chooses to spend his free time playing very high quality games and browsing addictive content on the internet, from an insane vast sea of choice that we never had when we were programming in BASIC.
> You wildly underestimate the power of a child's imagination.
In my experience, that imagination tends not to come out until kids are bored, and produced content keeps them from being bored.
Wait until your kid is actually programming to pass judgement. My son is finally starting to find some patience and just turned 15. It was easier for me when I was 12 because there was nothing else to do.
I also am getting the feeling that the trend is global because I'm involved in hiring, and the younger kids out of school all started programming in college, not in junior high like all my cohorts my age. My group asks specifically at what age candidates started programming. The theory was that early is good because it shows self-motivation, but we're seeing general trends that kids are starting later.
EDIT: BTW, the main motivation for my son's newfound patience for programming, unix, and shells is to escape parental controls and sandboxing.
If he likes Worms Armaggedon, he might like the Gorillas game: https://www.youtube.com/watch?v=UDc3ZEKl-Wc
I had a lot of fun hacking that game back in he day.
For example, my 5 year old, who is just learning how to read, can understand the beginnings of BASIC. She's super excited to see the TI-99 4/A print back what she painstakingly types, or to see the computer count from 1 to 5 with a basic for loop. She wouldn't know what the F is going on with Scratch, let alone Python.
BASIC is exactly what it's name implies. I'm going to move her to Scratch and Python eventually, but I have yet to see either meet the needs of the absolute entry level, very young programmer.
This makes an explosion at coordinate x=100, y=200 that is 50 pixels wide and lasts 3 seconds, including sound. Put it in a loop that slowly increases the size or decreases the duration. What boy doesn't want to have control over screen explosions? (I may be gender-stereotyping, but you get the idea.)
https://www.bootstrapworld.org/
Scratch before it making programming like lego's.
The situation isn't nearly as bleak as you indicate. I also found that I can counter that expectation by showing the labor and code involved in big projects. Then, I show them a small project that's still fun made by one person or a small team with associated code. Then, I tell them they can start there, make fun/useful things, and work their way up to bigger projects like their apps or AAA games. Only thing I run into at that point is laziness about putting in effort or just disinterest in favor of other pursuit.
I do need to do an update some time in future of exemplar apps to use for my examples with appeal to wide audience. Probably several or a pile of them with summaries so they can just skim through to get to what interests them.
While I can agree that there are more "interesting" things to occupy time, I disagree that simple things will always be beaten by a team of engineers. To use an example outside of programming and video games, there is a multitude of tricks you are learn with a deck of cards. You don't need elaborate magic rigs to be entertained.
Secondly, I'd recommend looking at what BASIC was capable of doing. I'm going to be showcasing the game "Missile!" (pg 35 of [1]) on an actual Apple IIe next month. It's going to take only 43 lines of code to have a GUI driven game. It's obviously limited, but designed to get kids interested in Computer Science. To produce the equivalent in a text-based programming language would require too much overhead - even in Python's case.
[1] https://drive.google.com/file/d/0Bxv0SsvibDMTVUExUjFhTURCSU0...
Also, before I started studying computer science, I liked the Unity Game engine as it was quick to implement something interesting and it was easy to find lessons and instructions online to develop in C# and the Unity engine.
They are simple to use, connects with the real world so you can actually get feedback and can be used in a variety of cool projects.
I've gone with Python, but I'm not sure I made the right choice (too rich, too much information to swallow before starting).
Despite that, my son is working on a car race game, all ASCII, using curses. He made his own track with pipes and slashes and is pretty proud of it.
To be fair, their most advanced device to play is a nintendo DS (not 3DS or 2DS, the original one)
But I still think it would have been easier in BASIC.
That was interesting.
Never forget that operational causality over computers is gained one step at a time.
In 2019, it's very hard to do anything "interesting" with BASIC when kids are surrounded by apps and games with hundreds or thousands of person-hours of development. "Hunt the Wumpus" just doesn't cut it anymore.
As others have written, Python is much more interesting because of the extensive library ecosystem. Integrating the physical world, graphics, controllers, sound, audio, network, video, etc. offers a lot more engagement than "Hello World".
Javascript is also interesting because it runs everywhere, and HTML/JS skills will offer good summer job money. :)