Six hundred and forty pages in fifteen months(journal.stuffwithstuff.com)
journal.stuffwithstuff.com
Six hundred and forty pages in fifteen months
https://journal.stuffwithstuff.com/2021/07/29/640-pages-in-15-months/
28 comments
> If you get tired of reading it, it can serve as a doorstop or protect you from small-arms fire.
I like the self-deprecating humor, and wish him well.
I like the self-deprecating humor, and wish him well.
Reading it did tire me out, because I couldn't put it down and ended up skipping half a night of sleep. So uh, task failed successfully I guess?
For any Dutch folks wanting to purchase the book, it's also available on amazon.nl ¹), and appears to be cheaper there than the .com or .co.uk options, thanks to free shipping!
¹) https://www.amazon.nl/Crafting-Interpreters-Robert-Nystrom/d...
¹) https://www.amazon.nl/Crafting-Interpreters-Robert-Nystrom/d...
Related discussion from a week back: https://news.ycombinator.com/item?id=27997167
I bought Robert's book "Game Programming Patterns", and although it is a bit OOP-heavy for my taste, I have enjoyed it and the illustrations are excellent.
Also, cool to see him pull a Knuth and writing his own typesetting and build system for the book!
Also, cool to see him pull a Knuth and writing his own typesetting and build system for the book!
TIL that books can have build systems. What a time to be alive.
Some used to write books using LaTeX a quarter of a century ago and it was pretty much a build system. You'd typically have a little shell script making backups, cleaning the mess from the last build, building the book in x passes (IIRC there was a first pass for the book and a second one for all the references), converting it to another format, maybe opening the result in a viewer, etc.
As for TFA: 640 pages in 15 months ain't bad. Some have a lot of discipline and can write five or ten pages a day, but that's really hard...
As for TFA: 640 pages in 15 months ain't bad. Some have a lot of discipline and can write five or ten pages a day, but that's really hard...
> As for TFA: 640 pages in 15 months ain't bad.
It took me 15 months to edit and typeset the print and ebook editions. The actual writing and illustrating part took me another ~4 years before that.
It took me 15 months to edit and typeset the print and ebook editions. The actual writing and illustrating part took me another ~4 years before that.
As a concrete example, see latexmk. https://mg.readthedocs.io/latexmk.html
Check out leanpub.com ... basically what it is.
Looking forward to grabbing a physical copy of this book. As a beginner, CI and Alex Aiken’s course at Stanford were a great place to start.
Bob also gave me a lot of insight on what it’s like working on programming languages in the industry when I reached out to him as an undergrad.
Bob also gave me a lot of insight on what it’s like working on programming languages in the industry when I reached out to him as an undergrad.
I love Bob's writing and his solid grasp of programming subjects that interest me like games and programming languages. For his next book, I suggest trying LyX and the book class with the Tufte layout for far less pain in the publishing process.
> For his next book, I suggest trying LyX and the book class with the Tufte layout for far less pain in the publishing process.
Can that stack produce well-structured, accessible HTML? Or are you suggesting that he still use HTML or Markdown as his source format, then use LyX only for the print version?
Can that stack produce well-structured, accessible HTML? Or are you suggesting that he still use HTML or Markdown as his source format, then use LyX only for the print version?
Oh absolutely. Stick with Markdown and export to HTML as needed (I use emacs and org-mode's built in converter for that) but pandoc can export from Markdown to LaTeX and then Lyx can import it no problem.
This may be the first technical book I’ve wanted to buy in a decade. Google searching really replaced the way I learn programming and I’m not sure why. I’ve always had access to Google or another search engine but I used to actually buy books.
[deleted]
Is this book workable for someone who knows how to program but don't have much of a formal education in CS?
Yes. I'm halfway through it now, and while I do have a degree in CS, all that's really needed is knowledge of Java and C. If anything, it's less formal than a compiler / PL course one would normally take during undergrad.
I have very limited programming experience in C and Java. Is that going to be a problem?
It depends what you mean by "very limited". All the code is provided to you, so you can get through the book by simply copying and pasting the provided code snippets. As long as you understand what the code is actually doing just by reading it, you'll be okay. The book has some "challenges" where you can implement additional features if you want to, but you don't need to. However if your knowledge of Java or C is so limited that you'll have a hard time even understanding what the code is doing, then it's probably not worth the effort going through the book. It will be too confusing, and you won't learn much.
[deleted]
Look at the free sample pdf on his site. Topic is garbage collection. If you can comprehend that then buy the book.
yes.
Yes, that's exactly who it is aimed at. If you can write code in an imperative language—in other words you're a typical software engineer—then you should be able to follow along fine.
The first half uses Java, but sticks with a pretty vanilla subset. If you're comfortable in another OOP language, you should be able to squint and figure out what's going on.
The second half uses C. That does assume you have some basic familiarity with pointers, malloc(), etc. but doesn't assume you're a C expert. If you're totally new to C, it might be worth spending a little time learning the basics if you really want to grok the last half of the book. If you mostly want to understand the concepts around bytecode, stack-based VMs, and Pratt parsing, you can mostly ignore the C details and get by.
Also, the code in the book has been ported to many other languages:
https://github.com/munificent/craftinginterpreters/wiki/Lox-...
So you can always use those as a reference too.
The first half uses Java, but sticks with a pretty vanilla subset. If you're comfortable in another OOP language, you should be able to squint and figure out what's going on.
The second half uses C. That does assume you have some basic familiarity with pointers, malloc(), etc. but doesn't assume you're a C expert. If you're totally new to C, it might be worth spending a little time learning the basics if you really want to grok the last half of the book. If you mostly want to understand the concepts around bytecode, stack-based VMs, and Pratt parsing, you can mostly ignore the C details and get by.
Also, the code in the book has been ported to many other languages:
https://github.com/munificent/craftinginterpreters/wiki/Lox-...
So you can always use those as a reference too.
Very much so. Source: I am 2/3 of the way through the book, and don't have any formal CS education whatsoever :)
This is super interesting and thank you for taking us through it!
Enjoy a whole lot of not anything in particular, now :)
Enjoy a whole lot of not anything in particular, now :)
I have been so far, and it's been delightful. :)
This is a great way to lead into the article. The author pulls off something that turns out to be extremely hard to get right: Interweave humor and slightly off-topic material into a technical post. Most of the time it falls flat, but not here. Looking forward to reading further.