Ah yes. One of the things I'll do when I'm learning a new computer language is pull out my now ancient copy of the 1973 edition of the book and just convert one of these games to the new language. The conversion might not look very much like the original when I'm done, but it is functionally equivalent. What I like about the approach is that the games in the book are small enough problems to solve as not really to be a major undertaking while being complex enough to be interesting.... and, of course, nostalgia.
Way back when copying these games from the book into a VIC-20 and C-64, along with a healthy dose of the 80's era computer magazine programs, were my introduction to programming. Having to convert between BASIC versions was part of the learning experience.
I remember "graduating" from Atari 8-bit BASIC to QBasic on an i386, and being blown away at how much more you could do, including switching graphics modes. I know a lot of people like to say that BASIC teaches you bad coding habits, but I think it also got young minds hooked into programming. If you had a deep interest, you unlearned those bad habits, but still kept that love of writing software. I still wish I could go back in time and feel what it was like to first gain a grasp of seeing your code perform some task, right in front of you.
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
-- Edsger W. Dijkstra
As someone who got their start with BASIC -- mainly from "BASIC Computer Games" no less -- I was always kind of offended at that quote.
As someone whose first language was BASIC, which led me down a path that eventually culminated in a CS Ph.D, I have also not been a fan of that quote.
It implies that Dijkstra was a terrible educator who could only truly teach blank minds. For all his imagination and creativity on theoretical CS and math, he was very rigid in other ways. Imagine a history professor saying that students who have been exposed to various myths and ideologies are mentally mutilated beyond hope, or a literature professor saying that students who have been exposed to pop culture retellings of the classics are mentally mutilated beyond hope.
Remember that Dijkstra looked down on anyone who wrote using word processors, because he thought any academic should be able to work out their argument in their head and just write it down. Eventually he came to even reject the mechanical typewriter.
Dijkstra's maxim is both harmful and clueless. Many of the greatest programmers in the world started with BASIC. When I "graduated" from BASIC to Pascal, I very quickly dropped the BASIC approach to program flow, as any software engineer worth their salt would do. Dijkstra infantilizes programmers, as if it wasn't obvious that BASIC's approach is cumbersome and people just keep programming C++ as if it was BASIC...
Once you go to a "proper" programming language, there is nothing to "unlearn". The new approach is so obviously better! At the same time, having an interpreter up within 2 seconds of turning the computer one was AMAZING and got a lot of people interested in programming.
Much of the software world you see today was built by people who started with BASIC!
BASIC is explicitly a beginner's language. It may not be the best design for advanced programming, but as an instructional tool for someone who doesn't even know what a program is, it's almost second to none. The lessons it teaches are profound: that programs are ordered sequences of instructions that computers can follow, that control flow can involve branching, loops, and conditionals and what those are, and the rudiments of breaking out a program into subroutines. This is a real mindblow for people who've never actually programmed before -- it means they can make the machine do what they want, even very sophisticated (from their perspective) things. It's only when you've seen better -- Algol, Pascal, Lisp -- that BASIC seems miserably wrong in comparison.
As for Dijkstra -- arrogance in computer science is measured in nanodijkstras.
Same, and I always hated that quote also. If anything, BASIC exposes you to low level assembly concepts: instructions are processed in order based on their 'address' (line number), unless you have a conditional, where you jump (goto) a new address. Variables are global by default, as they would be as data at an address in memory.
I suspect that BASIC may have got a bad reputation in the same way as PHP or JavaScript did, where the accessibility of the language and infrastructure around it allows people who just want to achieve a specific goal to easily participate.
That influx of people with the attitude of "I don't care how computers work, I just want to know enough to solve my problem" shifts the stereotypes around those language users and may erroneously put the fault of it onto the language itself. It certainly feels that way during hiring, where it seems like developers of vastly differing skill or aptitude tend to cluster heavily around certain "friendly" languages.
BASIC didn't really raise the abstraction level away from imperative statements and loops. It let us hack faster, but it didn't help us to write programs that were provably correct. I think that is what Dijkstra was getting at. He was worried students would think this was good enough. And he was right. BASIC influenced a generation, my generation. The generation that gave us arguably the next BASIC, Python. A language with little coherence, that mixes imperative commands and mutation with the lambda calculus; and has no static types. A language that makes easy tasks easier, but hard tasks harder.
It's a very Sapir-Whorf sentiment, that somehow we are infected by what we learn, unable to imagine outside of those formative experiences. And like Sapir-Whorf, also false!
Sapir-Whorf in the conventionally conceived sense of language-as-local-limitation is clearly false, partly as it invalidates itself as an origin story. (How would you invent a language if you can't think outside of it?)
Sapir-Whorf in the sense of language-as-influence however is clearly true, even if academics occasionally state otherwise, because at their core all languages used by communities of a size greater than one individual rely upon semantics that are socially dictated.
Personally, perl screwed me up a lot more than BASIC - but who can argue with the expressive power of regex for text extraction and matching problems?
I have noticed, however, that the more experience one has with C, the more flummoxed they are by Rust. It's why I tell C old hands who grouse about Rust: Rust isn't for you, it's for your replacement.
Do you think so? I would consider myself an Expert C programmer. I haven't written a C compiler but I can see how I would go about it, I know a lot of the weird arcana, and I followed WG14 enough to be heartened but not astonished when C23 got #embed while C++ still can't unstick their version of this work (and thus in practice if you're a C++ programmer you should hope your vendor's C++ compiler just offers the C feature anyway)
But I fell very much for Rust in about 2021, and now definitely wouldn't write any more C. Rust has coherent answers to a lot of questions that, to my mind, should be in any C programmer's head.
Now, maybe it helps my CS course's first language was SML/NJ and of course Rust is basically an ML in a trench coat pretending to be a semi-colon language like C. But that CS course was at least half a decade after I began writing C, which was in turn after many years of BASIC (and somewhere in there a little bit of Z80 assembler, but man assembler sucks when the CPU is as limited as the Z80 was, you young people who have a fucking floating point multiply instruction don't know what you've got etc...)
To me, the veteran C programmer, Rust's implementation makes lots of sense, while at the same time it's type system appeals to the more principled Computer Scientist I was taught to be, and its tooling to the Engineer I became as an employee.
Two examples: Wrapping<i32> is exactly how a 32-bit signed integer actually works in any vaguely modern computer. The machine can do this, and so unsurprisingly on a real computer this is nice and fast, despite also being completely safe. But, Wrapping<i32> is a nice elegant type, Wrapping is a polymorphic type, which grants to integers the property of wrapping (modulo) arithmetic for their normal operations, and so i32 is just a type parameter. Beautiful, and yet also fundamentally exactly how the machine works so it's fast.
Second, Option<&T> is exactly the same implementation as a C-style pointer. But it has the same ergonomics as rich Maybe types from a language like ML. So you use it in an inherently safe way, with the compiler catching many common mistakes you could make because they don't make coherent sense in the type system - but at runtime it's exactly the same performance as the nasty C code you'd have written where those mistakes wouldn't be caught.
Rust had include_bytes! from Rust 1.0, include_bytes! is philosophically the same thing, given a filename, it gives you an immutable reference which lives as long as your program, to an array of bytes from the file -- &'static [u8; N]
Me too! I even maintained an application written in Visual Basic in my spare time while working with Java professionally. I can honestly say I have 20 years of experience in BASIC :D
I learned a lot about programming by taking a book like this that was written specifically for the TRS-80 (which I did not own), and translating the programs to what I owned instead, which was a Sinclair ZX80. This primarily involved translating between different flavors of BASIC, but also deciding what I could arrange to leave out and still have an interesting game, due to the relatively constrained resources of my machine. Excellent experience.
I learned a lot about programming by taking this book and, since I didn't own a computer, figuring out how the code could produce the example listing. That's where I learned things like, to swap the values of two variables, you copy one to a third variable temporarily. I learned a ton of patterns like that.
Eventually I got my VIC-20, then an Apple ][, then an Amiga.
Somewhat related trivia: Sid Meier's Pirates! for the Commodore 64 is written mostly in BASIC, coupled with assembly for parts requiring snappier performance (for example the full-screen scrolling while sailing).
I still cannot wrap my head around this. I was schooled about this fact by one of the C64 experts who frequent HN, and I'm still amazed.
C64 BASIC was terrible even for its time. Due to licensing issues, its capabilities lagged behind those of other BASICs from home computers of the same era. Everything cool you could do with it was basically cheating: PEEK and POKE. As a child, this frustrated me to no end. Even my friend with his Speccy had access to a better BASIC.
And still... Pirates! was made with Commodore BASIC.
It had to be a horrible experience for him since for sure he was familiar with other BASICs. One example: Prior to Pirates!, in 1982, Sid Meir made a game called Chopper Rescue in Atari 800 BASIC:
C64 BASIC had to be a step back, but that's where the sales were to be made. For example, in Atari 800 BASIC variables were not limited to two characters.
C64 BASIC was really PET basic from ~1976, very close to Microsoft's Altair BASIC.
I programmed in PET basic in 1977/78 on my PET 2001 computer with a tape drive. Oh, the memories! And trying to explain to my mom and dad what the large thing on my desk was, and what could you do with it. Dad would bring up Colossus:The Forbin Project (the 1970 movie, which I saw a few years before buying my PET used for $832 in NYC).
C-64 BASIC V2 has all of the same important fundamentals that other BASICs of that era had. What mainly set it aside was the lack of dedicated graphical functions. What was available on the other home computers was on one hand too slow (or too limited) to be useful for pretty much any type of game development - forcing those platforms, too, to "cheat" by interacting with the hardware by POKEing around - but on the other hand fun and educational to explore graphics programming with. The exception would be the very capable BASIC of the Sharp MZ-700 which was of an entirely different class. For the C-64 there were plenty of third-party options.
Well, the C64 itself was a capable machine, so it's no surprise extensions to BASIC had cool capabilities. The issue is that the provided BASIC sucked, no if or buts about it. I remember missing a simple LOCATE statement for placing text (text! not even graphics) that the Speccy's BASIC had, if I remember correctly.
To me, missing dedicated graphical functions (or cool text functions like LOCATE) was a big miss precisely because the C64 was a multimedia computer. As a kid I wanted to do cool stuff with my C64 and had to resort to obscure (to me) POKE commands. "POKE" is not really BASIC, it's a cheat.
I remember when I finally got my PC-XT clone, loaded with GW-BASIC. It had a DRAW statement! I could draw pixels with easy to understand commands, no POKE! My mind was blown. I could even forget I was using a monochrome CRT... I wouldn't get my colors back until a few years later.
My opinion from having written so much in all kinds of BASICs back then is that it is convenience more than unlocking doors. Learning, for example, the two memory addresses to POKE to on the C-64 to move the cursor to a fixed position is a tool one learned no different than learning the more convenient alternatives of "PRINTAT" and "LOCATE". But I do agree that drawing lines etc. directly in BASIC provided a lot of fun. BASIC, by its nature, was the real limitation.
> "POKE" is not really BASIC, it's a cheat.
I don't understand why you don't consider it BASIC, or why it's cheating. Practically every BASIC out there from that era allows for direct interaction with the computer's memory. It's fundamental functionality of the lowest level possible, and the diametrical opposite of cheating.
It's because POKE in C64 felt to me like an excuse not to implement the actual command, "we give up, here's how you interact directly with the hardware". It feels the wrong level of abstraction. I now understand why they went this route (a combination of a poor licensing deal and the need to keep the BASIC implementation small enough to fit in memory), but it still left a bad taste.
And I'm speaking as 10-year old me, who didn't yet understand programming languages: Commodore BASIC felt incomplete.
Spectrum BASIC had PRINT AT (which is probably what you're thinking of). The C64 would probably have to use control characters to achieve the same thing in BASIC if it's anything like PET BASIC (inverted playing card suit characters etc.).
Ah, yes! PRINT AT. I didn't know PETSCII had control characters to place the cursor, but in any case, I think everyone will agree that's more obscure than a nice high-level PRINT AT statement.
(Still, I'd love to go back in time and tell my young self that I could use control characters instead!)
PS: pretty sure there was at least one BASIC that had a LOCATE command, or am I confusing programming languages?
PPS: well, duh! It was GW-BASIC that had LOCATE. No wonder I remembered the command, GW-BASIC was my first true love and the first language with which I actually programmed games.
Original BASIC was actually developed with a JIT compiler, only the 8 bit home versions were purely interpreted, and mainframe BASIC already supported structured programming and AOT compilation by the time 8 bit home computers were taking over, e.g. VAX BASIC.
I think many of us that started on 8 bit as kids, and eventually used something else on 16 bit computers aren't aware of this.
That was a pretty common mix, I know mostly from the CPC, but it was the same in (another) green, basically.
Been a kid at that time, I run into performance issues with the BASIC-only approach pretty quick. Sadly I had no good books about assembly or knew someone knowledgeable about it.
Just select the game you want to to run from the top-left list box, then press the "Compile" button and you'll see the translated JS source in the right text-area. Then press the "Run" button to run it.
What I'd really like to see are the multiplayer games from the original 101 BASIC Computer Games ported to the web. I was too young to understand how those worked as a kid, and my dad's copy had some printing issues (occasional pages have white streaks across it).
EDIT: To clarify BASIC Computer Games != 101 BASIC Computer Games (the original has more than the microcomputer version including CANAM and DOGS)
I wasn't aware there was a difference, I mainly just remember the copy of the book I had all those years ago and incorrectly assumed all the content was ported from the original.
Maybe you could cheat: there are a fair few emulators of that era of machines that you can SSH into, drop the code into one of those and run as originally intended! Or access via the web by hooking shellinabox up to connect to the emulator's console. You'd need to add some layer of authentication if making this available on the public internet for friends to access though. Might be easier to setup than actually porting that old “minified” code (with single-character variable names, GOTO-a-plenty, & minimal comments) and implementing something to manage multi-user access to the same game instance.
Thanks for the heads up on the web-capable versions of the other games. That's pretty cool indeed.
I hope someone takes on the few missing multiplayer games from the DEC version at some point but figuring out how to port them is going to be a lot of work!
There are copies of the book on eBay, so it is available if you want a better copy to work from yourself. A quick search finds copies on archive.org too, though you might have to check a few to find a good one (the one I just opened wasn't a very clear scan, the code was not particularly easy to read due to being a low-res scan of already low-quality text).
--
EDIT: having looked at the repository, it is reimplementing the games from that book in various languages, including javascript hosted in a web page, so for a direct translation it is exactly what you are looking for. If you want the multi-player ones to be playable between remote players, you still have some work to do!
The library in the city near where I grew up had some variant of this book in it. Unfortunately, the variant of BASIC was something that didn't compile on the 286 my parents had purchased and either I didn't ask or they couldn't help me at age ~5/6 to get around the compiler errors, and I thought I wasn't smart enough to be a programmer for about 8 years.
Then I got into the mid-wave mod scene in 1998, and I realized I had the wrong compiler, but man, I just thought I couldn't follow directions right.
(Personally I grew up on the British early 1980s Usborne BASIC programming books, now wonderfully available at https://usborne.com/gb/books/computer-and-coding-books . My copy of "Computer Battlegames" - which I'd arbitrarily picked in the bookshop over "Computer Spacegames" - was the closest to the classic "BASIC Computer Games", which I never came across - not sure if it was more a US thing.)
Ahl's collection is more diverse: it has battle games, board games, sports simulations, economic simulations, even rudimentary demoeffects ("Sine Wave").
One of the variants of the Football (American football) game called "FTBALL" is particularly intriguing; you will notice that the playable team is Dartmouth. This game is traceable back to Dartmouth College, where and when BASIC was first developed by Kemeny and Kurtz. It was, as I recall, originally written by members of the Dartmouth football team as a way to have a bit of fun. The idea that someone who wasn't a scientist, engineer, or professional programmer could program a computer to some non-tech, non-business purpose was a huge mind blow at the time, and a major contributor to BASIC's enduring popularity.
I contributed to a few of these last year because I wanted to learn a new language. These programs are hard to translate if they are sufficiently large. One way to cheat is to look at someone else's translation to a familiar language like Python then make your translation from there. The problem like that, as someone mentioned elsewhere, is that if you are not careful then you are copying over their bugs blindly (in addition to the original program bugs). We were encouraged as part of the project to try to stay true to the original design. I did add in some error handling. I also found bugs in the python decomposition of a few of them (I don't remember which one's and didn't have the time to fix them).
The People's Computer Company published many BASIC games in its publications (PCC Newspaper, People's Computers, Dr. Dobbs Journal, Recreational Computing) and in the book, What to Do After You Hit Return: Or, P.C.C.'s First Book of Computer Games. Many of the games were reprinted elsewhere, often without attribution.
I love the old Usborne BASIC books... and the old type-in BASIC program books. I have in my collection a few of those. I love the work of Jeff on converting those old games to JavaScript.
As I mentioned, I'm also impressed by the old Usborne books, therefore I also tried recently to create an illustrated JavaScript course in that style ... See here the first 30%:
I had a book like at that at age 10. I would spend what seemed liked hours typing them in to play the games… and usually there was a syntax error and they wouldn’t work, and often I couldn’t fix them. But I was fascinated and kept trying. The games I got to work were that much more rewarding!
2950 PRINT "TORPEDO TRACK:"
2960 LET X=X+X[1]
2970 LET Y=Y+X[2]
2980 IF X<.5 OR X >= 8.5 OR Y<.5 OR Y >= 8.5 THEN 3420
2990 LET V[4]=X
2991 LET V[5]=Y
2992 GOSUB 9000
Becomes...
_2950: Console.WriteLine("TORPEDO TRACK:");
_2960: X = X + _X[1];
_2970: Y = Y + _X[2];
_2980: if (X < .5 || X >= 8.5 || Y < .5 || Y >= 8.5) goto _3420;
_2990: _V[4] = X;
_2991: _V[5] = Y;
_2992: _9000();
Went to look on eBay for a copy, had one in my youth. Immediately crossed my mind to show it to my dad, who passed in 2020. Sad. That many memories. Oh my.
My dad passed in late 2019. Not long after, I had a vivid dream in which I showed him a programming book I thought he'd like, then we browsed the computer section of a bookstore for what felt like a pleasant hour or so.
Ah, this is really good. I'm thinking about teaching Python with a focus on game programming for my friend's son and my own son (in perhaps 6-8 years).
I think it could be pretty fun to dump a Raspberry Pi 8GB (with all software installed) and a keyboard in front of him and start programming small games. I'm sure there is a way to use game programming to teach from scratch. I just need to find an introduction book and adapt it with game programming examples.
But one issue is that kids today are getting used to things like Roblox so I'm not sure whether they would enjoy programming simpler games. I think a "graduating" project could be an Ultima-I spinoff, or some 2.5d engine such as Wolf3D's, but simpler.
For the most part it is! I contributed to this project last year or so. The goal was to make the ports as one file runnable equivalents and not get all enterprisey but you can see (mainly C#) that some people can't shake the habit. There was also a lot of "we need a framework for running the programs", "we need a framework for testing", and "we need a linting and style compliance" efforts.
If you don't know BASIC then you'll have a hard time following the spaghetti code that the original book has. Probably half of the BASIC programs from the original book are either actually broken, have bugs or don't work as intended. Of the people that contributed, they either included the bugs and bad logic, ported from someone else's port in another language (that included new bugs and kept the old ones) or wrote a different game entirely.
To create a truly verbatim port in as many lines as the original while fixing the original bugs (and making it readable) is quite time consuming.
Interesting point that replicating all the logic of spaghetti code can take a lot more lines than the original. Still, some of the op-ified code I just read seems unnecessary.
Yes. If it is sufficiently original to be a distinct work (most human translations will be), it is a derivative work with its own copyright; if it is, e.g., a purely mechanical translation, it is covered by the copyright on the original.
In either case, without permission or a copyright exception (e.g., fair use) it is also a violation of the original copyright, either as a derivative work or a copy.
IANAL, but my understanding is "yes, that would be considered a derived work". Of course, it really only matters if you expect to end up in court over it.
Translating ancient programs like this are unlikely to trigger a legal case, but I would not rule it out entirely in this day and age.
It is weird to see Java listed as a "scripting language". Although these are all very loose definitions, I'd assume Python, Lua, Tcl, Perl, Ruby, Basic...etc as scripting languages.
I wrote a small script to load Hamurrabi.bas onto my Apple-1 replica over serial and to play against it interactively, as a sort of screensaver.
Though I played this as a kid, I learned some interesting anti-mechanics by writing an "automatic player", that I can still get the highest rating by systemically starving 3% of the population each year, and that there is no need to leave any food in store for the successor after your final turn, and that losing half of the population to plague is actually in your favor.
I'm always happy to see more BASIC promotion. I just love the nostalgia from being able to make my old 386 make a sound by just typing BEEP.
When Sean Astin used a variant of BASIC to crack a security door in the second season of Stranger Things, I even wrote a blog post about it. I was just so excited to see BASIC again "in the wild."
101 BASIC Computer Games (the original book, published by DEC) is literally how I learned to program back in the mid-70's, on a small PDP-11 sold as a kit by HeathKit that my dad built. (Paper tape! Woohoo!)
Just thought I would add that Modern != Better. You can still write shite in 'modern' languages and a well written program is that regardless of its language
Way back when copying these games from the book into a VIC-20 and C-64, along with a healthy dose of the 80's era computer magazine programs, were my introduction to programming. Having to convert between BASIC versions was part of the learning experience.