Why 80s BASIC still matters

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.

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.

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....

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.

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.

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.

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.

It was same feeling for me too, in the early/mid 80s. And it was impressive also because few other people were even doing it. Whether other people could or not, based on their capabilities, most didn't actually have any home computer to even practice on. Merely having a home computer in, say, 1983, was a rare thing. Actually being able to make it do things you wanted was even rarer. It probably seemed more impressive to many outsiders than it actually was (in the sense that a for-loop is pretty boring/basic) but hard to separate out that impressiveness between having access to the situation at all vs having the skills.

IIRC the guy who wrote the checksum generator also wrote the common assembly language graphics routines we used for all the games.

[1] https://tic.computer/

[2] https://www.dragonbox.de/en/45-pyra

Nowadays the expectations are so much bigger. I've seen people create their first website and be disappointed it looks so crappy, rather than excited it works at all. Not everyone, mind - some are still excited.

(It's good that Microsoft still has a BASIC out there that you can point kids at. BASIC was Microsoft's first product and absolutely left a legacy across the decades.)

Also, I feel that as long as schools continue to require Texas Instruments graphing calculators for tests, that TI-BASIC will probably long have a place for teenage experiments when bored in classes.

(C having a callstack is actually a pretty big deal, and not everyone adapted to it well at the time.)

I agree, but this is exactly what the linked article does. It even promotes the idea that the GOTO is better than functions or OOP, because it’s “simpler”. Needless to say, I disagree.

Naming things is almost a prerequisite to be able to think and reason about things without keeping the entire program in your head at once. And without any means of abstraction with names for code, old-style 80s Basic fails this requirement.

“I liken starting one’s computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act.”

— Ken Pier, Xerox PARC

OK, sounds great. I also remember the versions of Basic on the Amiga and Atari ST being perfectly adequate in this regard.

But this is never the version of Basic which people talk about! What you describe is not the version of Basic used by all those listings in magazines, or in the linked article. This is, for all intents and purposes, not the “80s style Basic” which everybody remembers with such apparent and baffling fondness.

Um, yes? That’s exactly what I meant by “an even more limited form of Python's style of lambdas”. Which is what they are. I never used them myself; I never, ever, found a use for them.

The rest of your argument seems to be “If you’re careful, it’s techically possible to write structured code.”, but the same can be said of most any language. Even assembly language for $FOO’s sake, usually has labels!

Qbasic is also a sort of weird situation-- modern in some ways, but sometimes feature and resource limited compared to other BASICs. It was a defeatured QuickBasic that they sort of expected users to graduate to the full product.

Modern languages pack in tons of indirection because that's where the power tools are - but an introductory environment might benefit from cutting down on that.

Lol, found out later why that was bad, but as a kid, why not?

What else are the numbers for?

In all cases they were people that could already do some stuff in Office VBA, got IT to have them a VS install made available to them, and just coded away on VB.NET when needed.

It helped that many devices in life sciences tend to have Windows only drivers, sometimes COM based, as such on their specific domain, having .NET based applications around was already pretty common anyway.