My first major programs were written under the influence of Knuth—I spent a lot of time reading the source code of TeX and its related programs and learned a lot from that. In fact, I only ever took one computer science class in my life (I went three times and got a C), so I'd have to say that Knuth was by far the most formative influence on my early programming. The other day I was actually looking to see if there was any trace of the DVI previewer I wrote for VM/CMS back in the 80s around on the internet. As near as I can tell, there is not. It'd probably be embarrassing to see (among other things, I didn't do any caching of font bitmaps, mostly because I didn't know how and didn't have time to learn, so every character displayed on screen re-read the bitmap data from disk).

How do you get pixels on a screen from VM/CMS?

There were two graphic output options in the previewer. There were specialized graphic terminals using the GDDM protocol (this code was actually written by someone in Germany who sent me their changes). The original code that I wrote used Tektronics graphics protocols available in the terminal driver that connected to the mainframe via a protocol converter that enabled the use of cheap ASCII terminals instead of the standard dedicated IBM terminals.

Oh man, you were drawing pixel fonts on a 4014 storage tube? That must have taken forever.

It was an emulation of it on a PC. VT100+Tektronix was a common graphics option on terminals of the era and the PC terminal software provided that as its graphics choice. I had some optimizations like replacing any characters below a certain threshold size with a solid box based on the bitmap's bounding box. It was reasonably fast given the speed of the connection.

I think it's potentially dangerous. When I was first learning to program, there were a lot of things I couldn't figure out how to do. Then I came across an algorithms textbook (Algorithms in C, by Knuth's student Sedgewick) and it explained how to do a lot of things I had never been able to figure out how to do before, and with beautiful code. This was a wonderful revelation! I then spent a lot of time studying algorithms.

Unfortunately, I didn't learn how to program! I thought that what I was missing was knowledge about algorithms, and that was occasionally right but mostly wrong. Worse, algorithmic textbooks bias you to look for the one weird trick that makes your apparently complex problem simple. But usually that trick doesn't exist, and when it does you usually have to solve the problem the hard way first before you understand the problem well enough to find it. The process of debugging, refactoring, optimizing, and testing that gives rise to the final polished form of a program cannot easily be inferred from what remains. Books like The Practice of Programming and Code Complete were much more helpful, but you can't learn to program by reading books, any more than you can learn to play baseball or win lawsuits by reading books.

I did eventually learn to program pretty well, though I'm not yet a master of the craft like Knuth, Jeff Dean, Rob Pike, Walter Bright, or Norvig. I did it largely by a practice described in this interview: writing new programs every day. I also learned a lot from pair-programming, which taught me both to read other people's code (we had collective code ownership) and to write code others could understand. My main obstacle was not ignorance but perfectionism and lack of practice.

I used his books as a way to learn the things about computer science that I missed out on by not having a CSci degree. They are very mathematical, but that's just a bonus for me. They are certainly not light reading.

> I missed out on by not having a CSci degree

I have a BS & MS in CS, and most of the material in TAOCP was still new to me. Even the stuff I thought I knew like hash functions was covered in a new depth I never would have imagined.

I often consult the "Seminumerical Algorithms" volume, as someone who has to implement lots of digital arithmetic. It is wonderful to help me base my choice of algorithms on math. I wouldn't recommend it as a way to get into programming though, as it is more about algorithms than about how to code them in a practical language. Perhaps his books on literate programming would be better for this purpose.

I try to implement in Emacs Lisp Knuth's combinatorial algorithms from

https://www-cs-faculty.stanford.edu/~knuth/fasc2b.ps.gz

I just managed to finish the first Alg. P (plain changes); it was really hard, considering that I didn't understand the algorithm and the description is made for Pascal like languages.

> Seems like an interesting way to get into programming.

This would be an iconoclastic route into programming, to say the least.

If you are looking for a more approachable or practical book that gets you programming and introduces some theory I recommend “Classic Computer Science Problems in Python” by David Kopec.

Reading TAOCP to get into programming is sort of like reading a physics textbook in order to build a doghouse in your backyard.

Iconoclastic? What idols are being smashed by our hypothetical TAOCP-reading novice?

Not the best word choice. s/iconoclastic/singular/

perhaps the learn how to program X in Y days "icon"?

He wrote a love story about Surreal numbers. I haven't read it yet but it's on my list FWIW.