It's Saturday folks!

Chapter 9: Generation

Still in line with the theme of the book, the chapter is about taking
a data-driven approach to programming, focusing on data representation
that can easily be visualized and understood instead of the algorithm.

The tree-like structure of the config reminds me of ALSA
configuration. However, ALSA conf is very opaque, and is "incidentally"
Turing complete.

The ascii table reminds me of the talk by mort in the nixers conf 2020 about
including binary data in C executables.

Chapter 10: Configuration

I like how configurations are described as the "startup environment",
it makes it way more explicit what this is about and how we should think
about it.
Unless the configuration is continuously read, but then the question is:
Would that be a good use of configuration?

The big question of the chapter is: What should be configurable? And the
Unix instant reply would be "everything" but that is too overwhelming
to novice.
So the author goes to ask the reverse instead, "what thing should not
be configurable?"

Then, again with the theme, we take an approach of least surprise,
no burden, and human-first.

"Run-control files" is a much cooler term for startup config files
and dotfiles.

Environment variable are also well described as "global context, what
is available, and should be available, everywhere".

On the command line option, there's another category that wasn't considered:

The "sub tools category", the programs that start with a name such
as openssl and then followed by a sub command. The sub command itself
takes flags.
I can thing of git, openssl, imagemagic fork called graphicsmagick "gm",
busybox? and others..

There's also the "split programs framework" approach: When a "software"
installs a bunch of other sub-software/tools as framework.
Either all these software in the "framework" start with the same
prepended form, fc- for font config for example. Or they come
under a single tool to avoid confusion.
Sometimes it's annoying if a software installs subtools in that
"framework" but they all have very different name, it makes it hard
to find related functionalities, discoverability is very low.
Again, I'd say this is an observation in tune with the book: ease of
use for human-brains.

The list of single char flags with their expected meaning should
definitely be consulted when writing CLI software.