troydj

He says in the book (right after introducing that example), "if you have trouble with import std;, try the old-fashioned and conventional #include <iostream> ..." And he shows a snippet with that.

To really appreciate the need for awk, imagine writing one-liners and scripts in the late 80s where Perl or Python weren't present. The associative arrays in awk were a game changer. Of course, today there is no need to use awk for multi-line, complex scripts because Python or Perl does the job better (and both languages are more scalable). However, awk is still quite useful for one-liners. But for those developers who never use the one-liner paradigm of pipelines on the command line, this is something they don't realize they're missing.

Brian Kernighan mentions in the book that awk provides "the most bang for the programming buck of any language--one can learn much of it in 5 or 10 minutes, and typical programs are only a few lines long" [p. 116, UNIX: A History and Memoir]. Also keep in mind Larry Wall's (inventor of Perl) famous quote/signature line: "I still say awk '{print $1}' a lot."

More background on awk from Brian Kernighan in a 2015 talk on language design: https://youtu.be/Sg4U4r_AgJU?t=19m45s

Thank you for sharing your methodology.

A pointer to the study that you're probably thinking of is research done by Paul Nation and Robert Waring (vocabulary researchers). They cite their own 1985 study and a 1989 study with the following quote: "With a vocabulary size of 2,000 words, a learner knows 80% of the words in a text which means that 1 word in every 5 (approximately 2 words in every line) are unknown. Research by Liu Na and Nation (1985) has shown that this ratio of unknown to known words is not sufficient to allow reasonably successful guessing of the meaning of the unknown words. At least 95% coverage is needed for that. Research by Laufer (1989) suggests that 95% coverage is sufficient to allow reasonable comprehension of a text. A larger vocabulary size is clearly better." [1]

1. http://www.fltr.ucl.ac.be/fltr/germ/etan/bibs/vocab/cup.html

Maybe if we all start sending tweets to @timoreilly he will reconsider this very unfortunate decision...

One of the things I'll miss is the "upgrade a registered O'Reilly print book to an ebook for $4.99" option. Always nice to have both the print and [affordable] ebook versions. Bummer.

One way would be:

   perl -nae'printf("%s:%s %s\n",$F[2],$F[0],$F[1])'

I learned Awk in 1988 before Perl was around (on our systems, anyway). It was super useful at the time. But if you know Perl and Perl is available on your system, there's certainly not a compelling need for writing standalone, multi-line Awk programs. But Awk is really, really useful for one-liners. As Larry Wall has said: "I still say awk '{print $1}' a lot."

Brian Kernighan himself, in this 2015 talk [1] on language design, states that Awk was primarily intended for one-liner usage (he mentions this at 20:43).

[1] https://youtu.be/Sg4U4r_AgJU?t=19m45s

Yes, agreed! You'd think most of the CS people in a room listening to a Lamport lecture, of all things, would've at some point in their education taken a theory of computation or similar course. The notation Lamport was asking about is already taught by page 7 of chapter 0 in Sipser [1].

[1. https://www.amazon.com/Introduction-Theory-Computation-Micha...]

Linus' "good" version has a McCabe cyclomatic complexity of 2, whereas the "bad" version has a value of 3. So, objectively, one could argue there is improvement there (albeit small). Validation of the "good" version will be easier (e.g. code coverage testing) with fewer paths through the code. Additionally, a lower cyclomatic complexity typically implies less stress on the developer's working memory while reading code (since you don't have to consume an internal brain "register" holding the result of a conditional while following the flow of control).

It seems like the purpose of this book significantly overlaps with Cal Newport's _So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love_ [1]. Newport gave corresponding talks on this topic at Google [2] and elsewhere [3], and they cover his book's main ideas.

[1] https://www.amazon.com/Good-They-Cant-Ignore-You/dp/14555091... [2] https://www.youtube.com/watch?v=qwOdU02SE0w [3] https://www.youtube.com/watch?v=IIMu1PGbG-0

I wouldn't go so far to say that the Dragon Book is outdated and irrelevant. (I'm assuming you're referring to the 2nd edition from 2006.) Unless you're focusing on back-end optimization and code generation techniques (something a new compiler writer typically does NOT do), the bulk of the theory and material you'd cover in a first semester compiler course is fairly static.

But if a person is merely looking to bang out a compiler without getting overwhelmed with how to convert NFAs to DFAs for lexing, etc., some good alternative books are:

A Retargetable C Compiler: Design and Implementation, by Hanson and Fraser (http://www.amazon.com/Retargetable-Compiler-Design-Implement...). This book constructs and documents the explains the code for a full C compiler with a recursive descent approach (no flex/lex or bison/yacc). I have some experience augmenting this compiler, so I can vouch for the book's ability to clearly convey their design.

Compiler Design in C, by Allen Holub (http://www.holub.com/software/compiler.design.in.c.html). Downloadable PDF at that link as well. A book from 1990 in which Holub constructs his own version of lex and yacc, and then builds a subset-C compiler which generates intermediate code.

Practical Compiler Construction, by Nils Holm (http://www.lulu.com/shop/nils-m-holm/practical-compiler-cons...). A recent book which documents the construction of a SubC (subset of C) compiler and generates x86 code on the back end.

Don't be depressed. This is normal. All memories are subject to gradual decay. The best way to prevent this decay is by reviewing and testing yourself on the material you want to remember. Unless one reviews or uses specific knowledge regularly, corresponding memories will fade on courses taken, books read, bugs fixed, technologies or languages learned, code that's been understood (read) or written, etc.

If you only spent a few weeks working on that new project, then you probably didn't spend near the amount of time Bill Gates spent writing, thinking about, and reviewing his Altair BASIC code. Even though he whipped up his code in less than a month or two prior to the first MITS demo, he likely spent weeks or months after that demo modifying and polishing the BASIC interpreter for subsequent releases. You didn't mention your experience level, but Gates' years of prior programming experience likely benefited him as well, providing him with a nice cognitive framework to which lots of these facts could "stick."

One additional thing: when Gates says he still knows the source code for Altair BASIC by heart, it probably doesn't mean "completely, line-by-line" by heart. I'm guessing it means he still remembers some snippets by heart, or that he believes he could re-write it from scratch from memory (which would still be exceedingly impressive).

Some useful resources on memory and learning:

Memory and Learning: Myths and Facts (http://www.supermemo.com/articles/myths.htm)

Want to Remember Everything You'll Ever Learn? Surrender to This Algorithm (http://archive.wired.com/medtech/health/magazine/16-05/ff_wo...)

Make It Stick: The Science of Successful Learning (http://www.amazon.com/Make-It-Stick-Successful-Learning/dp/0...)

The original abstract for the talk (which summarizes the slides) were posted by the author here:

http://blog.cr.yp.to/20150314-optimizing.html

I'm waiting for jgrahamc to post a 40% off No Starch Press coupon code for the loyal HN readers (in celebration of his newly-published book, that is :).

Nice recommendation. Looks like the 3rd edition was just published this month. Bryant's blog describes the updates to the 3rd edition here: http://csappbook.blogspot.com/2015/02/the-third-edition-will...

Andreas Zeller, original author of GNU DDD, has a good book called "Why Programs Fail: A Guide to Systematic Debugging", 2nd edition.

http://www.amazon.com/Why-Programs-Fail-Systematic-Debugging...

Noticed that the price is double the price of the 1st edition. Is that due to the number of authors doubling? ;)

A more up-to-date and complete treatment of these exact topics can be found in the recently-published book, _Make it Stick: The Science of Successful Learning_ (http://www.amazon.com/dp/0674729013/). For those that have already immersed themselves in spaced repetition techniques via Anki, SuperMemo, Mnemosyne, etc., some of the material in the book will be review. But there is a wealth of useful information for both students and lifelong learners. In addition to that, the intertwined, real-life case studies and anecdotes drive home the points. And lest my comments come off like a back-cover endorsement, I will say that I was a bit disappointed that the authors seemed to have little awareness of SRS' momentum on the Internet with the aforementioned programs. For example, even though the book spends quite a bit of time discussing spaced repetition and flashcards, it never once mentions Anki, SuperMemo, or other popular SRS software. Aside from that, it's still an excellent book.

Part of the confusion, I think, is that people unnecessarily require "perfect pronunciation, hearing, and intonation" in their definition of "fluency". You mentioned that your wife is fluent in French, but does not have native-like French "hearing". Perhaps she also speaks with a non-native accent. That doesn't detract from her fluency. Arnold Schwarzenegger, for example, would be considered to be fluent in English even though he speaks with a heavy accent.

Babies and pre-pubescent children do indeed have a distinct advantage when it comes to learning sounds, tones, and pronunciation for a language [1][2]. It's also been observed that children are more likely to sound native (in language 2) if they move to another country and learn that second language prior to puberty (see again, Nagle [2]). So, gbog, if your child speaks/hears French, Chinese, and English regularly before hitting puberty, he/she will likely sound native in all three languages. But this advantage doesn't nullify the claim that adult learners can still become fluent in a foreign language. It just means that adult learners might never sound exactly like a native speaker, even though motivated learners can achieve near-native pronunciation in their target language [3].

[1] Babies are born with the ability to hear/distinguish between the sounds of all world languages, but this ability starts to diminish around the age of 10 months (pp 39-40, The Bilingual Edge, King and Mackey, http://www.amazon.com/The-Bilingual-Edge-Second-Language/dp/...).

[2] "Critical period research clearly demonstrates that the probability of a near-native L2 phonology rapidly diminishes as we age", Charles Nagle, "A Reexamination of Ultimate Attainment in L2 Phonology: Length of Immersion, Motivation, and Phonological Short-Term Memory", http://www.lingref.com/cpp/slrf/2011/paper2913.pdf

[3] "The results of this study highlight the fact that learners appear to be able to achieve near-native pronunciation without significant formal instruction in pronunciation which perhaps also evidences the role of implicit learning in L2 phonology...", Nagle, http://www.lingref.com/cpp/slrf/2011/paper2913.pdf

There is also a reference to this method on page 61 of SICP (footnote 40 of exercise 1.18).

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-11.html...