It's extremely hard to write good tutorials. This one is very clear, but seems to have no time budget or reader model. I appreciate the clarity and the extensiveness, but it mainly makes me wish for something different.<p>Today there are so many IDE's and online coding environments, godbolt, Swift playgrounds, golang interactive tutorials, etc. It would be lovely to see a C++ tutorial join that trend.<p>I find the tutorial unsettling from the first words: `original, self-contained`. My first step in writing a tutorial would be to link the current state of the art, and the last would be a section pointing users to further resources, if my goal were not to trap readers but to help them. (Originality is a tall claim as the internet spawns LLMs.)<p>Without any orientation to the landscape, the tutorial proceeds step-by-step with topologically-sorted vignettes that explain themselves verbosely.<p>hello-world is prefixed by a long explanation why people start with hello-world, and following by 16 paragraphs of (to me) excruciating hand-holding and suggested experiments, without re-quoting the code. It's like pair-programming with someone who tells you what to type.<p>The original K&R book was breathtakingly brief, mainly just showing you how to do things. Effective C++ neatly crystallized specific problems and solutions. Both benefited most by what they left out.<p>Outside of an interactive tutorial for newbie's, what's needed for "modern" C++ is an origin story for each feature: what motivated it, how backwards-compatibility shaped it, what design decisions were made, how well it has been implemented and used -- ideally with bonus comparisons how Rust and Swift and Go managed the same issues. I think that would help people remember the complex issues and the syntax, and how to use it.<p>To me most of the discussion from the C++ originators is more expository than explanatory: `for each opinion, explain in detail with cross-references to other opinions` - the political template. But readers only need to know the distinctions that make a difference in when and how they use a feature.<p>Actual users are busy and paid only to get things done, not sling words. Users who value their time will pay for a good resource.