The reason I have that source code to Empire and none of the rest of the code I wrote on the PDP-10 is I saved everything to a magtape. Unbeknownst to me, the magtape machine was way out of spec, and the tapes were only readable on that machine, which is long gone, so I threw the magtape away. And so disappeared the earlier BASIC version of Empire.
I downloaded Empire over a modem to some 8" floppies on a PDP-11. I also saved a paper listing of the code for insurance. I eventually bought my own LSI-11 which could read the floppies, and later rigged up an RS-232 connection with Kermit to transfer it to a PC with 5.25 floppies. From those it eventually went to a CD, a hard disk, and finally to github.
Fortunately, I never needed to type it in from the listing, and tossed that.
Walter! I feel like I'm speaking to a celebrity! My Dad has been playing Empire since I was very young. It was a staple in my house growing up. He still plays it every day. He buys every version he can get his hands on. His love for Empire rubbed off, and my favorite genre of games are war management / 4X games (but SciFi!). Thank you so much for your amazing game. Is there a way I can contact you outside of HN (email)? Would love to ask some Empire questions :)
Random question, is it just me or is programming significantly easier now with all of our modern tools. Even within my own lifetime, I find newer programming languages such as NodeJS to be infinitely easier than C++.
Although occasionally I'll see some scripting frameworks which actually appear to imitate the older keyword based style.
Thank you for sharing by the way. I hope one day someone can learn from my old code
As a mostly (ancient!) hobbyist programmer - so take my views as a bit grumpy - we seem to have developed such complex toolchains and frameworks, that the industry suffers from 'goldfish bowl' syndrome in that the IDEs and tools have grown in complexity and size to fit the complexity we've created (that's a bit recursive!).
I know it's a crude comparison, but consider the likes of installing Turbo Pascal and a few libraries ('units') from back in the day with what I had to go through to setup the vscode-based toolchain on Linux for the Raspberry Pi Pico, which required me to fudge a script: https://github.com/linker3000/Pico-setup/blob/main/pico_setu..., and I almost gave up after 3 days of on-off tinkering trying to follow various instructions to get the same IDE running under WSL due to various quirks and changes which made the online instructions out of date or missing key tweaks.
I even approach platformio with a degree of trepidation for fear that a bucket-load of stuff will need to be updated before the odd bit of code I've hacked together will compile this time round.
Perhaps if you've grown up during the mainstream days of Eclipse, Platformio etc., their appearance and behaviour are just second nature and I'm just looking at the past through rose-tinted glasses! Oh well, back to configure and make - I can handle that!
Very few frameworks have yet to match the simplicity and performance of using something like Turbo Pascal with Turbo Vision, or later Object Windows Library.
Compared to today, in the 1970s and 1980s some things about programming were harder and some were easier. Back then, computers were amazingly slow and limited, by modern standards, so it was much easier to understand how they and their comparatively tiny operating systems worked. But coming by that understanding could be difficult. There was no internet, no Stack Overflow, no GitHub. Just books, magazines, and driving to nearby colleges to meet with other computer nerds in so called user groups. Another challenge was that computers back then were so slow and so limited that to solve what today would be considered easy programming problems often required you to invent a succession of clever hacks just to fit your ideas into such a miniscule computing vessel. (One example: https://blog.moertel.com/posts/2013-12-14-great-old-timey-ga...)
In sum, getting started in computing was probably easier back then because you worked in such a small, simple computing environment. But, compared to today, the difficulty ramped up rapidly with the complexity of the problems you wanted to solve. At some point your solutions would run into the limitations of the machine, and then you had another problem to solve. That made it hard back then.
Bang! Immediately whole areas of complexity relating to concurrency are gone. While you could write for a multi-user timesharing system like UNIX on the PDP-11, the common home computing target was:
- boot instantly from ROM
- small API (of necessity)
- fixed API: no need to worry about updates if you can't update
- shallow API over the hardware
- hardware itself fairly simple: just write directly to framebuffer
- zero information security considerations
You didn't have to worry about updates, dependencies, compatibility polyfills, etc. This limited what you could do, but perhaps not to such a great extent as it might appear.
On the other hand, information was a problem. If something wasn't in the manual, you either had to reverse-engineer it, or buy or borrow a huge thick expensive non-searchable book and hope it had the information you needed.
(I have a pipedream project of "BASIC for the web", if I ever flesh it out it'll get posted to HN)
So many of the modern problems are because the computer is a battleground, both in the infosec sense and the market dominance sense.
> (I have a pipedream project of "BASIC for the web", if I ever flesh it out it'll get posted to HN)
Back in the late 90s when my IDE was “what I can get on a MacFormat cover CD”, I started using what was then called REALbasic. It was very similar to Visual Basic, even sharing most syntax with whatever version my 6th form insisted we used. Over time it added more compilation targets and changed its name to Xojo, and judging by their website it now supports websites as a compile target.
I'm not Walter, but this is the internet so I'd like to state my opinion where is wasn't asked for. ))
Programming really isn't easier, but it is far more accessible. In the '80s (I can't go any further back that that, sorry) one had to be able to do things properly in order to do anything. Today, one can copy and paste high-level code from public websites to get their programs to do more-or-less what they want under more-or-less trivial circumstances, without even being aware of the corner cases.
But doing it right? Still takes the same dedication to detail. Big difference is finding people to pay you to do it right instead of paying 1/4 the salary to someone who will code bugs and security issues that may lay dormant for half a decade before costing the company dearly.
Though, truth be told, most of that code won't last the half decade anyway. So there certainly is something for expedience and being first out the door.
Is it really more accessible? Computers used to boot into a BASIC prompt. Now the devices we most commonly use don’t have any sort of programming environment built in.
You can actually bootstrap a small text editor on mobile browsers using a data: URL and a tiny text editor in html (literally just a form with a text box that will download a file with the contents of the box when you hit submit).
A pain, and not accessible if you don't know the google incantations to figure it out, but doable.
I would say that a higher percentage of the population of any developed nation can go from "I don't know what a computer program looks like" to running print() in a REPL in far less time (the only real measure other than Money, right?) than could be done in the 1980s.
If we're talking about "people with a desktop computer readily at their disposal" then I'll agree that in that subset it may be more difficult today than it was 35 years ago (when computers booted into a BASIC prompt), but only a little bit. However, that subset went from 3% of the population to 97% of the population, greatly increasing the pool in general.
> higher percentage of the population of any developed nation can go from "I don't know what a computer program looks like" to running print() in a REPL in far less time
But I suspect a far smaller percentage of those who can actually do.
I think it depends on your definition of programming; the technology to build complex systems has undoubtedly improved, however the bar for hobbyists and learners is now sadly far higher than it was in the eighties, when almost anyone with a home computer could knock up a fun little game in BASIC as per the article. What could we recommend to the eager youngster for this sort of stuff today? JS + HTML canvas? Pygame? Not even in the same league of approachability sadly.
> however the bar for hobbyists and learners is now sadly far higher than it was in the eighties
I mean, the initial friction of getting to hello world is higher than with boot-to-BASIC systems, but the marginal friction for anything beyond that is vastly lower.
The bigger deal is that almost any common need has readily available free adequate solutions; there's far less for a hobbyist to do that feels like a payoff compared to easy-to-find, free, off-the-shelf software. There's less magic.
When you read Walter's FORTRAN code from ~1978, keep in mind the environment in which he wrote that code and edited it.
Most likely it was all typed in and edited on a Lear Siegler ADM-3A [1] terminal. Depending on when the code was written that terminal would have been running at either 1200 bps or 9600 bps [2]. That's a 24x80 ASCII terminal that may or may not have supported lower case (lower case was an option on the ADM-3A and not all of Caltech's had it).
There were maybe 20 terminals in the terminal room that most students used. There was no scheduling or reservation system. You just had to go there and see if there was a free terminal. (I seem to recall there was a rule that people doing actual class work had precedence over people just doing their own thing, and there was a rule against games during the day [3]).
For actually editing code I don't know what editor Walter used, but it probably was not a screen oriented editor. Most of us used TECO [4].
With the competition for terminals, and line or character oriented editors instead of screen editors, you tended to do most of the thinking about your program away from the computer at least for medium or large programs. You got it all designed in your head (or on paper), worked out most of the details, and then at the terminal it was mostly more typing than programming.
Nowadays with no more competition for computer access and bigger screens with editors that show much more code (and with much more powerful navigation features) we don't need to put nearly as much upfront thought in to our code. For most things that is fine but for some problems figuring it all out in your head first would be better, but I think a lot of programmers no longer learn how to do that.
[2] All the ADM-3As in the computing center at Caltech were 1200 bps when I got there in 1977. Sometime later the operators accidentally configured one to 9600. We users asked if we could have them all changed, and they did so.
[3] But that rule was against playing games during the day, not writing games during the day. Testing and debugging a game during the day was unclear.
You nailed it. I used TECO, first on the DECWriters (which printed on paper) and later on the ADM-3A's using TECO with a TECO macro that turned it into a screen editor. My editor today (microEmacs) is really not much different from that. A couple ASR-33s were available, but I wouldn't use them as they were soooo slooooooow. There was a Tektronix terminal with the green screen storage tube, too, but being a storage tube made it unsuitable for screen editing and playing Empire.
I'd often print a listing, and take it back to the dorm and go over it with a pencil making changes that I'd later type in. I usually was at the Jorgenson computer center in the wee hours of the morning when terminals were available and the PDP-10 wasn't slowed to glacial speeds by everyone else using it.
On Christmas vacation, I'd fill spiral notebooks with handwritten code I'd type in when I got back to campus.
I don't write code in pencil anymore, but I often do work it out in my head while jogging.
I don't recall when lower case was available, but Empire being all in upper case certainly suggests it was not when I wrote it.
The lack of lowercase and symbols on some terminals is why languages in the Pascal and Ada tradition are case insensitive and eschew some ASCII symbols, even today. You can even trace some of the weird syntax in COBOL like DIVIDE N INTO X to similar concerns.
> You got it all designed in your head (or on paper), worked out most of the details, and then at the terminal it was mostly more typing than programming.
Very true, and people would even use pre-formatted "coding form" paper back in the day, to ease that hand-coding process further. It was just hard to do real interactive development while working at a hardcopy terminal, so smart 'glass teletypes' with actual full-screen editing were a significant innovation.
You’re right about preprinted coding forms. I wrote a lot of code in Ryan-McFarland COBOL in the late 70’s, and used coding pads I bought at the college bookstore.
In some companies, coding forms were sent to keypunch operators. They took your input forms and punched them quickly and accurately onto 80 column punched cards for you.
It's only easier if the complexity of what you write these days remains the same.
I started with Basic on Z80 as a kid, continued with Pascal and C++ on Dos, and these days I'm writing microservices running in Kubernetes Clusters. I did desktop programming on Windows, systems programming on Linux, games, old fashioned MVC Web apps.
I feel that what we deal with today are several order of magnitude more complex and harder than what we had in 80s and early 90s. At that time the most difficult thing was finding information and documentation and maybe trying something for the first time without prior examples. Now we have to fight complexity.
I have been for 40 years. It is much the same the write a program to solve a simple problem once you learn the language. Some might be a little simpler at some problems where the libraries support what you want to do, but, on the whole, the same. Where things have changed a lot is 'presentation', which has become much better, no easier, maybe harder and 'deployment', which has become much harder simply due to the quantities of parts. Like a car, a lot more parts, individually no more complex, yet much more complex due to so many connected individual parts.
I think C (and later C++) made things unwieldy harder.
Sure, you needed a higher-level ASM and C filled that space, but there was a void between that and the (very) high level languages like BASIC, bash/awk etc that took some time to be adequately filled (and maybe even today isn't)
The in-between is Forth. BASIC (and Python) are 50 times slower than assembly or C. Forth is 5 to 10 times faster than assembly or C and 5 to 10 times slower than BASIC or Python.
Smalltalk, Scheme, ML (the language), and Emacs existed in the 70s. But they were way less evenly distributed. The comfiest programming environment on my mid-80s home computer was Forth.
(My code from back then was lost when the machine got stolen along with my floppies.)
I love that the Empire manual has a section that suggests readers "Wire up an interconnecting cable as shown..." Long gone are the days when computer games came with manuals, let alone manuals that are so detailed they actually tell you how to wire up the cables you might need.
I'm glad that I don't have to solder up my own RS-323 cables anymore, nor worry about whether they were crossover cables or not.
But still, I wrestle with Ethernet, several types of USB, HDMI, RCA, phono, F, BNC, quarter inch, disk, VGA, DVI, connectors. I have a box full of adapters. That all sux.
I had a similar experience with a BASIC game I wrote in 1987, which I revived recently in an emulator - the code itself was copied directly from ancient hard-sectored 5.25" floppy disks into a virtual disk image.
The emulator had a bug in it, though-- it would scroll up the entire terminal if the static 25th line ended with an Enter or line feed, something that didn't happen on the original H/Z-89 hardware. I fixed the game by adding a single semicolon to the end of the PRINT statement.
I remembered the old Star Trek game game from the seventies. Many versions of it are available on line, but each was specific to a particular version of basic - versions I didn't have.
I ended up downloading one of the more promising versions of Star Trek, and then implementing a basic interpreter to run it, in python.
For me, part of the fun was implementing things like code coverage and data breakpoints. Tools I never had then, but were handy to have to find issues now.
My astronomical 6502 assembly routines (ca 1987) compile and run fine in embedded simulators. Through the years it has always been in my todo list to port them to C, then Lisp, then C++, then Java, then Python, then Rust... But alas they do exactly what they need to do so the priority to rewrite them falls out of the map. And the main project why they were written in first place, a telescope interferometer controller, still remains unfinished.
I have late 80s DOS utilities I wrote which I still use semi-occasionally, and some slightly newer (early to mid-90s) Win32 ones that see regular, even daily use --- the same binary works on Windows 10. I still have the source but I don't remember the last time I fixed a bug in any of them. The modification dates are all closer to the turn of the century than now.
A few years ago I found a box of old floppies that had a bunch of code I wrote in high school. Some BASIC, some Pascal, some C (some Unix and some Turbo C), and some Prolog. Mostly games, assignments and a couple of attempts at making shareware.
BASIC did little to abstract logic and flow control and most interpreters only had global scope for variables. As your software got more complex, it got harder and harder to debug. Additionally, no real way to do any real dynamic data structures - you had only fixed length arrays.
Turbo Pascal was great, but had lots of little annoying limitations. String length had to be declared up to 256 characters (I think this got fixed in a later version of Delphi). These limitations made it harder to do lots of things that were really easy to do with C.
Prolog was really cool - but it was useful for a limited set of uses. I wrote a couple of tries (really cool to my 15 year old brain) at adventure games, and prolog made a lot of it really easy since most adventure games were all about collecting a set of conditions to solve some kind of puzzle.
C was easily my favorite - it was harder to understand at first with pointers and having to manager memory allocation, but you could build anything you wanted with it. There were a few programs where I implemented in BASIC, and then rewrote them in Pascal, and then in C. Each time, the application became more useful because a lot of limits were removed.
Honestly, C has really held up well, and a lot of that has to do with having no artificial limits... you still had hardware-imposed limits though. C did have a lot of built-in footguns... That said, I really love a lot of modern languages - so easy to do big things.
The oldest program-like thing I have is a game written in the Adrift interactive fiction engine from 2001. Unfortunately, it's password protected and I can't remember the password. I wonder if there's an easy way to crack it.
Sadly, all of the other programming I did in high-school is lost.
I find these stories to be comforting. This chap is an old-school, hardcore, nerd. I can totally relate.
I actually have a scanned PDF of the operator/maintenance manual for my very first professional engineering project[0]. I wrote that in 1986-7 (I also wrote the manual, and a later manual, for the host package[1]).
The company is long dead, and I’m sure my baby has since been melted into slag, but I was very proud of it. It was my first real engineering project. I keep the manual around, to prove that I have been architecting significant software, from the very start of my career.
The manual includes the full listing of an entire firmware operating system, written in Intel 8085 ASM.
The host package was a mix of ASM (MC68000, I think), Pascal, and HP BASIC; designed as a driver system, for integration into programs written for early HP workstations. I don’t have listings for that, but there are a few snippets, sprinkled throughout.
Has anyone tried playing an old cassette tape, from a commodore for example, on a tape player, audio output to computer.
Then transcribing?
It would be cool to see how good or relevant some of our old programs might be.
I have a mining program, from 1982, that calculates overburden tonnage, and so on, from user inputs.
Similar to old DOS software, later updated to Windows, etc.
I have programs written by me in the 80s. They were written in North Star BASIC and COBOL. I also have C programs written by me (say) 10 years old.
When it comes to working out what the programs really do, and how they do their work, the COBOL programs are a breeze. The C programs and the BASIC programs, not so much.
Lame, but I wrote Prolog that year. I read about it on some magazine and there was no mention of the cut. So I invented new definition symbol ":=". Under that rule there is no backtrack. It looked actually better and was more comprehensible than "!".
I just searched back in my old files and found a simple C program that I wrote and was last modified in August 1981. I just now tried compiling it and although it threw up some warnings about return types and implicit declarations, it compiled fine and seems to run fine.
One of my personal websites contains lots of game code I wrote going all the way back to 1978 when I shipped my first game. And one of my other personal websites contains many of my notebooks (since typed up) going back to those halcyon days of making an interesting game in just 500 bytes or so. 6502 C compiler. Word processor. Sprite utils. I've been slowly pushing my code on to github too, no matter how bad or disorganized it is. There are typed up notes of me working through how to juggle bits to fit more words in to a memory for a word puzzle game, or figuring out how to make a Minotaur hunt you down in a maze. It is amusing to look back on those notes at times.
I have a program that old I just keep using and don't have "to bring it back to life":
Given two text files A and B with the lines sorted in ascending order, write a file C with the lines in common between A and B. Sure, the program is just a little command line thing with name AINTERB for A intersect B since the program is a version of intersection in set theory.
Ah, there is another one: Given a text file A with the lines sorted in ascending order, keep only the unique lines. So, that name of that one is UNIQUELN.
One more, XBLNKLNS, for delete extra blank lines, that is, so that there are no cases of more than one blank line adjacent, in a row, together.
I am currently pulling BASIC and Z80 assembly programs from cassette tape that me and my dad wrote in the late 70s early 80s - games and robot armdroid drivers for the NASCOM 2, a kit computer from 1977.
Most run in the emulutor but luckily I have the original NASCOM2 and 2 armdroids so (hopefully) I can get my dad's physical SOMAS cube solver from his master thesis running again.
Older than that is a punch tape teletype 'program' that I wrote thank you letters for me, pausing for input of the names of grandparents.
I still have the source code for a DOS game I wrote around 1990/1991. I still have a few executable files and I've got all the code and the assets but I don't have the toolchain anymore and I don't have the build script neither. I don't remember which compiler I was using. So basically I've got no clue as to how to build it.
But a blog like this surely makes me want to bring it back to life at some point!
>>>>for non-old-timers, it was fairly common back in the day for magazines to publish code printouts, that users would then type in by hand to run on their computers<<<<
Yea, HTML/Javascript code in the newspaper for me. Too bad, I had to do the running of the code in my head only.
Oh man, I just did the same! I have some code written in the late 90s in common lisp. Most of it ran like a charm, except for the console graphics that used some very obscure library I never found.
Very cool stuff. Relatedly, I happened to click on the Ataribreakout.online link he posted at the end of the article, and it is actually surprisingly playable and enjoyable on mobile!
https://github.com/DigitalMars/Empire-for-PDP-10
I thought backing it up using github was a good idea.
A modern version that will run on Windows can be obtained from:
https://classicempire.com