I'd be interested in this if it were nearing completion. I think structuring the book around problem-solution pairs is a nice technique. But it would be a much

I'd be interested in this if it were nearing completion. I think structuring the book around problem-solution pairs is a nice technique. But it would be a much better read if fewer irrelevant statements of opinion were strewn in. Also, a lot of the bizarre statements of irrelevant "fact" should be checked, for example: > In the Old Times, creating a repository was days, weeks of work. I can't begin to comprehend what this may mean. "svn create" (or whatever it was called) was always instantaneous. Setting your project up for network access took longer because you had to read docs and write a config file, but the same is true for Git. > Optimizing compilers (...) may remove assertions. Bullshit. Using NDEBUG removes assertions, and yes, this indeed means that assertions must be side-effect free. But an optimizing compiler? No. If that actually happened for calls to impure functions (and no, it really doesn't happen), it would be a major compiler bug. > a nasty reminder of the old days when computers stored data and code on different kinds of rust, and languages enforced that Code and data do live in different places in memory; nowadays more than ever, for reasons of security. C's original "declarations before statements" rule (the context here) was simply because it makes it much simpler to write a primitive single-pass compiler. > The standard C library often puts destination arguments first, which is a hangover from assembly language. MOV X, Y. ... or maybe it's an analogy with assignment statements, X = Y? Note that three out of these four examples are just irrelevant opinions, so they should be removed from the text even if they weren't factually false.