Dick Grune

I suggest starting with the old but classic Compiler Construction for Digital Computers by David Gries. Pair it with some modern books recommended here and you should be good. David Gries - https://www.cs.cornell.edu/gries/ and https://en.wikipedia.org/wiki/David_Gries Dutch computer scientist Dick Grune has written of Compiler Construction for Digital Computers that "entire generations of compiler constructors have grown up with it and they have not regretted it." Note that Dick Grune himself is famous for his books on compilers/programming languages - https://dickgrune.com/index.html and https://en.wikipedia.org/wiki/Dick_Grune

Also, for a very comprehensive survey on parsing techniques, I can recommend "Parsing Techniques" by Grune and Jacobs: https://dickgrune.com/Books/PTAPG_2nd_Edition/

When I started dabbling in programming languages design, Parsing Techniques - A Practical Guide was invaluable for me. I cannot recommend this book enough. First edition is available for free from one of co-authors site [0]. [0] https://dickgrune.com/Books/PTAPG_1st_Edition/ Edit: minor clarification.

> - The Art of Unix Programming by ESR Yes. TAOUP has a lot of good content about Unix programming styles and traditions, much of it useful generally. ESR's writing style is a bit heavy / verbose / uses verbal flourishes, but if you can let that not put you off, the book is worth reading. I've read most of it. One of the good sections is about Rules (of programming in Unix, which are not really rules, of course, but informal guidelines developed over many years of experience by many people - ESR has sort of codified them, a thing he tends to do a lot :) The Rule about separating the interface from the implementation is a good one. I've seen developers at even enterprise companies sometimes not follow it in practice. > - Parsing Techniques by Grune and Jacobs Just saw that there is a new edition of this book: https://dickgrune.com/Books/PTAPG_2nd_Edition/

If you are interested in going deeper, may I recommend "Parsing Techniques" by Dick Grune et al [1]. I have read this book over five times and still find gems hidden that I must have failed to grasp in a prior reading. The author provides the PDF of the first edition on his website [2]. Read the last paragraph of page 60 of the book (page 50 of the PDF). I read this again whenever coming in doubt. A great thing about the book is also its annotated bibliography. The author cites hundreds of papers for extended reading, but has also written a paragraph on each cited paper explaining the context around it, how it fits with the rest of the subject, and a quick summary of what were the key contributions and findings. [1] http://www.amazon.com/Parsing-Techniques-Practical-Monographs-Computer… [2] http://dickgrune.com/Books/PTAPG_1st_Edition/

Following on from some discussions about SCM history on here over the weekend I was poking around in the history of things too. The original 1986 CVS¹ is quite interesting from a historical prospective. Given that the implementation is just a bunch of scripts on top of RCS you can see how it plumbed together really easily. There is a note¹ on Grune's site, that explains the relationship between the scripts and the system people would more likely recognise as CVS(assuming you're old enough to recognise it at all). ¹ https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/usenet/ftp.uu.net… ² https://dickgrune.com/Programs/CVS.orig/CVS_BB_and_GNU Edit: And I guess you might not recognise the archives in the first footnote either. They're shar files which can be extracted using the files as a script or more simply with unshar from sharutils³. ³ http://www.gnu.org/software/sharutils/

This is just the usual wisdom on why estimates are off - nothing new here, except for an emphasis on regularly re-prioritizing. The real problem lies in not recognizing that some things either can't be estimated, or to get an estimate takes just as long as doing the thing. Example 1: Everyone's favorite magically autonomous puppet, Pinnochio! Imagine Pinnochio at rest. A simple system. What happens when ol' Pinnoak blurts out "My nose is growing!" What then, Jiminy Cricket? Example 2: Solving Rubik's Cube. Simple methods exist (http://www.dickgrune.com/Cult/RubCub/). You only need 20 face-turns to solve it (http://en.wikipedia.org/wiki/Optimal_solutions_for_Rubik%27s_Cube). Your Official CMMi Level 5 process requires you to have a written procedure so as to repeatedly be able to solve a problem within schedule and budget bounds. It's faster to take Dick Grune's document and solve the damn thing, rather than look the cube over, write down all 20 moves, and then do the minimum number of moves.

Languages are part of mathematics. Please read this fascinating book: https://dickgrune.com/Books/PTAPG_1st_Edition/ Parsing, generating phrases, understanding (analysis), etc, are all studied in applied math.

I am lucky to have found this Debian package https://tracker.debian.org/pkg/similarity-tester (source https://dickgrune.com/Programs/similarity_tester/ ) to help me detect plagiarism in my students's C++ code. The tool is perfect as it gives side by side comparison of codes to help see if there's a really an issue. Usually, it is easy to confirm by spotting specific constructions or even the positions of punctuation in code. I have found something for Python though.

This book seems to be available at : http://dickgrune.com/Books/PTAPG_1st_Edition/

Some exist already: http://www.harukizaemon.com/simian/ http://dickgrune.com/Programs/similarity_tester/ https://github.com/silviocesare/Clonewise

link to the link: http://dickgrune.com/Books/PTAPG_2nd_Edition/LowAvailability/

I had a hard time with Appel's _Modern Compiler Implementation in ML_ when I did the compiler course (7 years ago...) for my CS major. I much preferred _Modern Compiler Design_ by Dick Grune et al. (http://www.dickgrune.com/Books/MCD_1st_Edition/). A second edition seems to be in the pipeline (http://www.dickgrune.com/Books/MCD_2nd_Edition/).

I hadn't thought of writing a tail-recursive dumbsort, though I'm not sure this is really simpler (untested): void dumbsort(int *p, size_t n) { dumbsort2(p, n, 1); } int dumbsort2(int *p, size_t n, size_t i) { int tmp; return i == n ? 0 : p[i] < p[i-1] ? (tmp = p[i], p[i] = p[i-1], p[i-1] = tmp, dumbsort2(p, n, 1)) : dumbsort2(p, n, i+1); } > If the common case can be a single opcode like LOOP The thing about the 8086 LOOP instruction is that it does expose the loop counter conveniently; it's just CX (or ECX on i386, RCX on amd64). So restarting it is just a MOV (not an XOR, because it counts down to 0). Forth offers an instructive example of a set of operations (usually implemented in software rather than hardware) that support nested loops. Forth DO pushes both the loop counter and the upper bound on the "return stack" as what the ANSI standard calls a "do-sys"; there are words I, J, and K which get the innermost, second-innermost, and third-innermost loop counters, but cannot be used to set them. You can even save the contents of the return stack and restore it, but ANSI doesn't give you a way to restart the loop counter (which is certainly bad practice). But that's just a matter of portability; any concrete Forth necessarily has to have a reliable way to set the loop counter so…