No criticism of TACP intended, but I don't think you would find it very helpful in learning "how to program like the pioneers did in the old days." I don't reme

No criticism of TACP intended, but I don't think you would find it very helpful in learning "how to program like the pioneers did in the old days." I don't remember too many of my older colleagues in the 1980s having copies of Knuth. It was something you might encounter among computer scientists, but not day-to-day working programmers. We rarely thought about algorithms in that way when we were building business systems. If we did need an algorithm (maybe to sort some customer records that were stored on tape) we would dig out the IBM or DEC binders and look up the system call that we were supposed to use. I suspect that programmers who have grown up in the era of the PC would be surprised at how much the vendors supplied. The IBM mainframes came with huge libraries of software and documentation. I remember being given a UNIX box for a project at the telco where I worked, and being a little surprised at how little was included compared to the IBM or DEC machines of the day. There certainly were some good programmers around, but a lot of "development" consisted of taking a copy of some existing COBOL program and tweaking a few things to create a new report. Out of two or three years of working in COBOL, I don't think I ever wrote a program completely from scratch. As a creative outlet, it was much more interesting to work in C and try to figure out how the guys at Bell Labs were doing things. Those are the shoulders that many of us stand on today.