I had been programming for 5 years before I even heard of a debugger. Early debugging was reading core dumps (can you think how many pages they would take now), and stepping through the code by putting the processor in single-step mode and reading the lights on the console in binary to see what was happening. The only input devices were punched cards and console switches. The outputs were lights on the console, punched cards, and a line printer.

My First computer language was also FORTRAN, though a bit earlier in 1965. The first run of my first program caused a core dump because I left out a minus sign. I had no idea what that was at that time, but it seemed to excite the people assisting us in the lab. The corrected program got the results I wanted. Haven't used it since my student days though.

I spent way too much time playing this on a PDP-10 in the 70s. The original Fortran code was an engine. The first time it was run after being linked, it read the contents of a map file (map, objects, actions, etc) into memory and encrypted it. Then it exited leaving the image in memory. You then typed save to create an executable with the map loaded. It would have been easy to change the map but we never did. There were two mazes. In one every room's description was "You are in a maze of twisty passages all alike". In the other maze, every room's description was "You are in a maze of twisty passages all different". You might go North from one room, but to return you might need to go East or West. To map the mazes you had to leave objects in each room so you could tell them apart. Only the first 5 characters of a word were checked because 5 7-bit Ascii characters fit in in a 36-bit word. I never got into Zork but we did have another adventure game called Sewer that was written as a TECO macro. XYZZY, PLUGH, and other words from Adventure along with various characters from "The Lord of the Ring" were among the known likely passwords the internet worm tried.

Yesterday: Win 10 Desktop update in under 3 minutes; Win 11 Laptop in about 3 minutes; Win 10 laptop around an hour (Only one without an SSD).

Sometime in the 1970s one of our users reported a problem entering a date for a future event. The code was not written by us, but we had the source, so I pulled up the code to see how it worked. I found this comment (PDP-10 assembler) "Thirty days hath September, all the rest I can't remember, except February which never works anyway" There was no code to handle leap year! At least the comment helped us know we were in the right place. That isn't the worst comment I found in code from that source, but the worst would violate nsfw rules.

Some of us are too old. I quit listening to pop by the 1970s.

Born 1945. Didn't see a computer until 1953 though.

Back around 1975 ± 2 years one of the programmers at the newspaper where we worked wrote a simple program he named GAME1. He put the .SAV (like .exe or .com) file of it (TOPS 10 system) in the system area. When one of the people in the sports department ran it, it printed "Files Deleted" and listed all the files in the area with pauses to make it realistic. Typing control C which would normally cancel a running program caused it to print "I can't do that" and it continued listing files. It had also sent a message to the operator who had been made aware of the program, so when he called for help the operator told him he couldn't kill it. He said later he became physically ill since those files were stories that were supposed to be printed in the next edition. No files were actually deleted and the program exited once the several hundred files in that directory had been listed.

Test Data For nuts 1 7 4 2 3 5 4 9 8 For bolts 6 4 9 7 8 1 2 3 4 Does it meet the specifications. No, but then real data almost never is as the user said it would be. There are 2 matching 4s and one has an unmatched 5 the other an unmatched 6. Good data in > good data out Garbage in > report errors and depending on the situation quit or process what you can.

Interesting. My first home computer was a PDP-11 (15).

Now one of the dos/Windows versions. I first learned TECO on a PDP 10 in 1972 when my company moved from IBM to DEC. I used it professionally in TOPS-10, TOPS-20, RSX, and VMS. I now have Windows and Linux systems at home. If I could get a VMS system at a reasonable price I'd probably do so though more to get EVE/TPU than anything. Have been watching the group porting VMS to x86 with interest, but waiting to see what they offer to non-commercial users. Right now it looks like they offer a free limited-time license (alpha emulation) but you have to backup everything before it expires and re-download and re-install/restore. I'm not sure I want the hassle, though I loved working in that environment.

There are some tasks for which I still use TECO.

Sometime in 1985, I took my young son in with me while I did some work on a Dec_System-20. He happily played beside me by stacking some orange cones that were put out when the floor was wet, or so I thought. The next day I found he had turned off a disk drive on a Vax system. At that age, I couldn't have resisted the lighted button he pushed. Fortunately, the system was not critical. I think that message was posted somewhere, but then he couldn't read yet so it didn't matter.

I still use TECO occasionally. Learned it in 1972. I sometimes wrote TECO macros to do a task and while I was waiting for it to finish, I could write a Cobol or Assembler program to do the same thing, compile it and run it while still waiting for TECO to finish. It was really easy to use for scripting when the amount of data was small.

Probably in 1980 (or +- 4 years) had a user complain because the computer would not accept Feb 29 as a valid date. We had been using the software involved for about 3 years at that point. When we looked at the source code we found this comment. "Thirty days hath September. All the rest I can't remember. Except February which never works right anyway." There was no code to handle leap years! The quick fix was to change days in February to 29 so we could run the advertisement in the Newspaper on that date and have time to implement a correct routine.

I once created a really long password using all the allowable characters. When it came time to change it, the new password was rejected because it had too many of the same characters as the previous one. If the sysadmin had not been able to override that rule, I'd never have been able to use that system again.