I'm curious if there if any book or blogs that detail the design decisions, or the lack of, for some popular languages, from the perspective of language design and industry usage.
I could and have written a few toy interpreters, but I have no academic or industrial background (on the matter of language design), so it is useful to know why they put some features into a language, and why they don't. It is actually one of the most confusing parts of writing an interpreter for a toy language -- in all of my projects I simply pick a subset of an existing language I know about, e.g. Python or C.
For Python, you can read the PEP documents - Python Enhancement Proposals - and see the discussion of what was suggested, pros and cons, work done to determine the preferred implementation, and the final decision.
To get the best historical sense, pick a language feature that has evolved in several steps over a number of years, e.g. async/await, type annotations, the GIL, etc.
For ordered dicts, for instance, which is topical because of [1] posted two weeks ago, the relevant PEPs are:
- PEP372: The original collections.ordereddict proposal in Python 3.1 [2]
- PEP468: Making kwargs ordered in Python 3.6 [3], which also made standard dicts ordered.
It's pretty far back on my blog to-do list, but the key order guarantee that was solidified in 3.7 lost the opportunity for a further space optimization (for dicts where keys are frequently removed).
The Ada programming language has documentation about its design rationale that discusses the tradeoffs/options considered and why they made certain decisions. Really interesting even if you don’t use Ada since a lot of these decisions are made by every language’s designers.
The Design and Evolution of C++ by Stroustrup is a fascinating book. It only covers the early years of C++, but that's perhaps what you're most interested in.
I could and have written a few toy interpreters, but I have no academic or industrial background (on the matter of language design), so it is useful to know why they put some features into a language, and why they don't. It is actually one of the most confusing parts of writing an interpreter for a toy language -- in all of my projects I simply pick a subset of an existing language I know about, e.g. Python or C.