jasone

If you enjoyed that experience, read The Book of the New Sun, by Gene Wolfe (5 books, 1-2 and 3-4 commonly printed as combined volumes: Shadow & Claw, Sword & Citadel, The Urth of the New Sun). I re-read them this spring, and they remain among the top ~3 series I've ever (re-)read.

As for most book-based movies, the book is IMO better.

APLR(1) generates ~minimal parsers with the full power of canonical LR(1). Suitable for use with GLR, fast enough generation to be default algorithm. LALR(1) is obsolete.

The C47/R47 appears to use the 4-level XYZT stack design by default, but it has an option to use an 8-level stack (XYZTABCD). I really like the unlimited stack option that can be enabled in Free42, but 8 levels might be enough to keep from feeling cramped in practice.

The former merely exposes a `BlogPostRepository` class. The latter requires some mechanism for creating a generic object of concrete type, which is a lot bigger change to the implementation. Does each parametrized generic type have its own implementation? Or does each object have sufficient RTTI to dynamically dispatch? And what are the implications for module API data structures? Etc. In other words, this limitation avoids tremendously disruptive implementation impacts. Not pretty, but we're talking PHP here anyway. ;-)

The addition of infinite pages made my RM2 unusable. It's far too easy to accidentally scroll, and hugely disruptive. I checked for tuning improvements for a couple of software updates, then set it aside permanently. That such a "simple" change could doom the device made me decide to go back to real paper, in all likelihood forever.

Hard disagree. Yacc has unnecessary footguns, in particular the fallout from using LALR(1), but more modern parser generators like bison provide LR(1) and IELR(1). Hand-rolled recursive descent parsers as well as parser combinators can easily obscure implicit resolution of grammar ambiguities. A good LR(1) parser generator enables a level of grammar consistency that is very difficult to achieve otherwise.

This is an interesting read. As a software engineer who accidentally discovered the depth of Scrabble in middle age, I fell down a slightly different Scrabble rabbit hole. The probabilities behind the imperfect bag/rack state knowledge fascinate me, and I spent most of a year writing a strong Scrabble engine to explore the problem. I've put that aside for now, but it remains a background pressure on the computing problems I tackle.

I've spent a lot of time over the years using bit shifting to multiply/divide by powers of 2 in low-level code. At some point I grokked the connection with (base 2) logarithms and found myself using them as a mental estimation tool with surprising effectiveness.

Many of us programmers have powers of 2 memorized through at least 2^20 (and 2^10 ~= 1000 is close enough for decomposing and converting larger values), which makes rough conversion to/from the log domain trivial. The trick in estimation is to round to the nearest whole number when converting to the log domain, and try to alternate rounding direction for inputs that are not close to the upper/lower extrema. Keep a running total of the log-domain value as a whole value, and take the antilog as the final step. Given these simple rules, most estimates come within a factor of 2 of the intended value, and with minimal cognitive load. All you need to remember is the current sum and which direction to round the next input.