What Every Programmer Should Know About Enumerative Combinatorics -> Nothing.

It can be interesting to know something (or even a lot) about enumerative combinatorics, and certainly there are some specific programming contexts in which that's a hard prerequisite, but it's not a topic that necessarily concerns every programmer.

OTOH I think it would greatly help programmers, especially beginners, to have fewer click baity titles around.

As a fan of combinatorics, I love people looking into the topic. Though most of what a programmer would find useful are approximations or trends which are handled well by the Master theorem ( https://en.wikipedia.org/wiki/Master_theorem_(analysis_of_al... ). For those deeply interested in the deep math of combinatorics I recommend Flajolet, Sedgewick, *Analytic Combinatorics, Cambridge 2009.

For those who are not aware, knowing how to count the number of structures is (nearly) the same as knowing how to encode said structure as an integer (space-optimally) (the naive general algorithm would not have good time complexity); to convert to integer, simply define some ordering on said structures, enumerate until you find your structure, the index of the structure is the integer encoding; conversely, to decode, simply list all structures and pick the structure with the index of the integer.

This has the flavor of a post written by a programmer who got a particularly interesting interview question. They continued working on it when they got home. Hey, it's happened to the best of us (I was once asked to write "tic tac toe" and at the time I was really getting into functional programming and simple data structures, and for some reason I didn't stop working on the problem for a few days because I wanted to generalize tic-tac-toe in scale, depth, e.g. deeply nested tic-tac-toe, and dimension, where the board has more than 2 dimensions) but I'm not sure I would have written a paper "What every programmer should know about implementing nested tic-tac-toe on large arrays in high dimensions" because the answer is, almost certainly, nothing.

I find the presentation a bit confusing and I'm already very familiar with this material.

From a purely mathematical point of view, why this choice of topics? You correctly point out that counting partitions has no closed formula, but there are a lot of related problems (Sitrling numbers of the two kinds for example) which are of more practical utility (e.g. they are related to sums of powers formulas). If that's too advanced for your audience then why not present more standard tricks like combinations with replacement aka stars and bars?

From a programmer's point of view, you could have focused more on how to generate subsets, permutations, partitions etc. in a memory-efficient way, for example how the Python stdlib does it.

Also, the factorial number system and the binomial base of univariate polynomials are definitely not "alternatives to base 2 in computer architectures".

Don't take this the wrong way but I struggle to see who you are writing for.