I wasn't trying to equate it to a programming language, though. IMO, a config format shouldn't be more difficult to grasp than a Turing-complete language. To me, nginx conf is hard to gain proficiency in because the amount of experience to know whether a declaration is in the appropriate place or won't be ignored is very high. Obviously someone can indeed become proficient, but I've found it to be extraordinarily high for someone who just needs it occasionally; I really don't want to live in nginx land all the time, in part because I'm a software engineer and not really an ops person.
For instance, should `upstream` be defined at the top-level or under `stream`? If you have another server doing a proxy_pass to that upstream, does it also need to be under `stream`? This is in no way obvious by either looking at nginx configs or by reading the docs.
And then what if you have a web server? Does it need to be under `http`, or can it be top-level? It can be either one depending on who's config you're looking at. But if your server you're pointing to is already an HTTP server, why would you want nginx to use its own http serving on top of your HTTP server?
That's just a couple of examples. And yes, there are absolutely logical answers to those, but I do not believe that the nginx config format speaks for itself.
Documenting things that took time for you to grasp is a great way to learn, in my experience.