I started studying physics at the University of Mainz in 1978. At that time, the computing center had a Honeywell GCOS system, and that was my first "big" computer. I found it fascinating at first...until I came to know others, even before my first contact with Multics. In the early eighties they started planning a more modern replacement, which fortunately (for me) turned out to be a Multics system. I write "for me", because for, eg., those experimental physicists working in close collaboration with other groups in the world compatibility was much more important than anything else, and Multics was not what they expected, nor was it the right solution for their problems. Not that I was willing to concede the point. :-)
At that time I had started doing my diploma thesis in theoretical particle physics, and that is where REDUCE was important. Actually, REDUCE started as a software to automatically simplify the so-called gamma matrix algebra - an important formalism used in many of our calculations. A colleague of mine did group theoretical calculations for his thesis in REDUCE; often his program would run out of memory on the old GCOS system. With Multics there came MACSYMA, but it had either no package for our problem, or it was too slow. I think this explains why we had to have REDUCE for the new Multics.
I skip the sweet memories of my first weeks with Multics, when there were only a few (soon familiar) usernames, and many late night hacking sessions with a full screen editor (gasp!) instead of punch cards.
REDUCE itself was not the problem, it came (and still comes) with full source code, but it needed Portable Standard Lisp (PSL) to run on. As you probably know, Multics had MacLisp. They are basically the same, but subtly different: functions with different names, different calling conventions, etc. And there was no PSL implementation, nor did I understand enough to do one. After some months, the Multics REDUCE implementation arrived, and it sort of worked. Some features were missing, system integration was bad. But it came with source code, and I tried to understand how these people had coerced the MacLisp interpreter to behave, and how to improve it.
This was difficult: the port was done in France, hence the comments mostly in french, but scarce, and important documentation about MacLisp wasn't there at all. (Anyone remember "uusnap"?) So, I had to read (and understand) the source code, and more late night sessions followed. For those who don't know Lisp: you can rename and redefine any function on the fly, to the extent that the interpreter looks entirely different. So, basically there was a layer on top of MacLisp that made it look like PSL. This was done partly by renaming and redefining of Lisp functions, partly by defining macros in the RLISP interpreter so that it used different names for calling Lisp functions. RLISP is the bottommost layer of REDUCE; it's more or less Lisp, but with a syntax like Algol60. Bootstrapping REDUCE involves first reading a tiny RLISP interpreter written in Lisp, then compiling RLISP function by function until it understands all the syntax. (This was a bit of a problem, as the Multics MacLisp compiler could not generate compiled Lisp code directly within the interpreter; I had to call it as an external program and load the segment with the compiled function - yes, one segment per function, if I remember correctly! Only for bootstrapping: afterwards the whole interpreter was compiled into one Lisp segment.)
As the work progressed I encountered a new problem: bootstrapping the REDUCE interpreter took a bit more CPU time than was allowed for interactive sessions during the day. Guess what? More late night hacking sessions...and a lot of absentee processes!
In the end, we had a very nicely working REDUCE, and I had learned so much about Lisp and computer algebra that it became one of my obsessions. In 1990 I left the world of physics to make computer algebra my main profession. Nowadays I'm no longer working in this area, but it always remains a fond memory, and especially the beginning with Multics. Since then I love interpreted languages: I'd rather code in perl than touch a compiler. (Not python: how can someone who grew up with Lisp write code in a language that has lambda expressions but no closures? :-))