Command Line Fanatic

Author here! I actually did a follow-up where I looked at the table-based decoding: https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art007

This is from August 2016, and see also the follow-ups by the same author (who is here on HN: https://news.ycombinator.com/user?id=commandlinefan): • Reflections on another year of reading Knuth (September 2017) https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art063 • Reflections on Three Years of Reading Knuth (May 2018) https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art070 Stops at Volume 3. Reading all three volumes in 30–45 minutes a day over ~3 years means about 500–800 hours I guess. I actually think that's pretty fast; I can only do an average of about 2 pages an hour (not counting skimming around, which is fun too), but what little I've read has been a lot of fun. IMO for anyone looking to dip into Knuth these days it may be more fun to start with Volume 4A (and it was announced recently that Volume 4B is coming out in October this year!)

Programming a gzip (deflate) decompressor is a really good learning project. I did it last year, ultimately producing a pretty poor but working implementation [0]. I ended up modifying Mark Adler's puff example program to see the intermediary tables it produces to help debug my own implementation. I wish I had known about infgen (also by Adler). The other resource I would recommend, beyond the official specs is this article by Joshua Davies[1], also mentioned in the original post here. [0]: https://github.com/davecom/nflate [1]: https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art001

http://www.commandlinefanatic.com/cgi-bin/showpage.cgi?page=home is good deep dive into various topics. Enjoy the gzip explaination Matt might's 'blog' https://matt.might.net/articles/ is good read about various functional ideas and others https://aphyr.com/posts/342-typing-the-technical-interview funny post about how complicated balancing a binary tree could be https://tratt.net/laurie/blog/archive.html some intersting posts about various aspects of programming language tools

Related article from the same blog, A Completely Dissected GZIP File: http://www.commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art0… The author has a three-part set of articles about Knuth and reading The Art of Computer Programming: http://www.commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art0… When I first gave a serious look at literate programming, I felt that what Knuth & co. could (should) have done to best demonstrate it is to write a program to describe/output the PKZIP file format. The CWEB sources themselves might be good and all, but most examples of literate programming I've looked at, including (and especially) the infamous article opposite McIlroy, don't really do anything for me. I checked around, thinking that surely someone realized this and that it must exist, but I didn't turn up anything. It's the same today, as far as I know. (I did find a DEFLATE implementation in JS run through one of those documentation tools that purports to produce a literate program, but it's not a literate program in the sense that Knuth uses the term.)

Agreed. I don't think there is anything wrong with linking to one's own posts here, if they are relevant. I do it now and then myself. BTW, commandlinefan, your page: https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art055 has the right pane text overlapping the left pane (main body of post), at least when I increase the font a bit with Ctrl=+. (Chrome, Windows). Please check and fix if can. It happens for the other two posts about reading Knuth too. But not for your About page. FYI.

Working through the volumes is possible: http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art055 I read the volumes roughly 30mins a day, and try most of the exercises. Like the above linked blog post I at least attempt to just understand the question on the M[40]+ exercises which still can teach you something by merely understanding why it's a difficult problem.