troydj
Joined 13 years ago
Karma
246
Submissions
22
Member since
Sep 8
Recent submissions
Comment · 4 years ago
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.
Comment · 7 years ago
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
Comment · 8 years ago
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
Comment · 9 years ago
Maybe if we all start sending tweets to @timoreilly he will reconsider this very unfortunate decision...
Comment · 9 years ago
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.
Comment · 9 years ago
One way would be:
perl -nae'printf("%s:%s %s\n",$F[2],$F[0],$F[1])'Comment · 9 years ago
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).
Comment · 10 years ago
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...]
Comment · 10 years ago
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).
Comment · 10 years ago
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
Comment · 11 years ago
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.
Comment · 11 years ago
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...)
Comment · 11 years ago
The original abstract for the talk (which summarizes the slides) were posted by the author here:
Comment · 11 years ago
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 :).