Hacker News Reader

Comment by pan69 | Hacker News Reader

Writing a game, or any software in 1987 would be painstaking compared to the luxury we have today. Back then it was normal to run DOS and DOS can only do one thing at the time. You open your editor, write code, close your editor, run the compiler, run your program, test your program, exit program, re-launch editor, etc. Over time small improvements where made to this flow like a DOS Shell and even things like DESQView that allow for basic multitasking.

This is probably a better description (from a code point of view) on what you had to do as a programmer to write a game in the late 80s / early 90s:

https://cosmodoc.org/

View on HN

Erm, there was a reason why Turbo Pascal (and the other Borland stuff) was such a big deal.

And that dates to 1983.

TP was just so awesome, it was like a superpower compared to others waiting 10-20x as long for each build.

For me the big thing was all the latencies stacked together. Slow hard drives, slow floppies, god help you if you swapped, etc. The era was mostly waiting around for the beige machine to finally do its thing.

Thank goodness for modernity. Now we wait for white, black, or unpainted aluminum machines to finally do their thing. Sometimes, we never even get to see the machines. :(

No modernity for me, thank you! Now every time I add a component to my PC, it's a different color than the rest. It looks like a zebra, I swear.

Back then it was just "new" beige and "yellow-ish old worn" beige.

Zebras come in colors? Ours are all kinda monochrome.

Also, much like some people are Excel wizards, some people were Apple II monitor/mini-assembler wizards or MS-DOS DEBUG wizards, or whatever other thing already lived natively on the machine. If someone has strong knowledge of the machine, a handful of carefully targeted little software augmentations, and well-developed muscle memory for the commands, watching them use a debugger/monitor can be almost like watching someone use a REPL.

I spend all day writing C++ or Python, and like playing around with Turbo Pascal on a circa-1984 Kaypro 2 as a hobby machine - the projects are certainly smaller, but my edit-compile-run loop on my Kaypro is usually faster in practice (even running on a 4 MHz Z80 with 64KB of RAM compared to an 8-core 3+ GHz workstation with 64GB of RAM) than my 'modern' work. It's genuinely crazy to me how usable a 40 year old machine is for development work.

The annoying part most people don’t realize is that when your software crashed you often had to reboot the box

One would often design tools specifically for an application. Depending on how nuts you went with that it could be quite luxorious. Map editors are the obvious example but if you need to find space for a disassembler you might as well make it part of the application.

It was single tasking, but usually there was no need to close the editor to launch the compiler and test the program. IIRC, QBASIC compiled and ran the program on one of the F keys; even EDIT.COM had a subshell.

Turbo Pascal (and its sibling Turbo C) also had a text-mode IDE that could open multiple files, had mouse support, syntax highlighting etc. and if you ran your program, it would run it and when it was finished you were back in the IDE. You could even set breakpoints and step through your code.

Don't forget about Turbo Basic!

It was a great language and IDE for a young self-taught programmer.

Reply on news.ycombinator.com