I bought this book and I've been using it - but I'm writing the interpreter in Rust instead of Go. I really like it, and I think Go is actually a cool language for this due to its simplicity. I had very little Go experience but the language is drop dead boring, incredibly easy to pick up.
Tried to push learning Rust via the Go examples. It has been a great exercise, but highlighted the pain of dealing with various string representations in Rust.
I would say that while Go is boring, it is worth learning. It may not be anything too new or interesting but it'll likely change how you think about programming at least a bit - concurrency and error handling in Go are particularly accessible while still being different enough to change how you think about the concepts.
I say that as someone who really isn't a fan of the language.
Are createspace books still of a noticeably lesser quality printing than non-print-on-demand books? I saw a few a while (a few years?) ago, and the quality offended me, so I wrote off createspace. I'd be interested to learn that's not the case anymore.
(Just to preemptively clarify: The bad quality I mentioned was most noticeable when compared to a non-POD book. On its own, it looks OK-ish and you might not think anything of it, but when you look at it next to another book you can tell.)
The book itself seems pretty neat though! I'm a PDFs for tech books kind of guy, personally.
I'm actually really surprised by the quality. I expected, as you put it, "non-print-on-demand" quality, but what I got has no obvious flaws or defects and a really high quality feel to it.
I didn't really think about this that much before, it was more like "yeah, full colors, sure, why not?". Holding the proof copy in my hands I realized what a nice touch it was and that I haven't seen this in other programming books. Of course, the full colors come with a cost, but once I saw it, I couldn't go back to black/white :)
Monkey is such a nice language, clean and syntactically lovable. I wonder if the same theory can be applied to make a space indented language like python or nim, I'd like to make one.
I don't think that's true - \t happens at the beginning of every line in a block, often more than once, whereas BLOCK_STARTS and BLOCK_ENDS tokens are pretty easy to track with a stack or whathaveyou.
Of course you'll check the context too. But the same is also true for "{" occurs in many places with different meaning -- in struts, inside text strings, in interfaces (in Go), etc.
Besides it's not the \t that you need to find as a marker for e.g. scope start. Python has "def xxx():" for example, so you see that and you know you're in a function declaration scope, same way function (xxx) { in C works.
After you see that you only need to keep track of \t or " " in the beginning of lines (before any other character) to know whether you're still in the same scope or not. That's why you can't just have arbitrary whitespace count in Python lines, but you need to maintain the same "indent" in the same scope.
It is becoming quite popular (or maybe it was always the case?) that someone learning some topic and at the same time writing a book about it. Interesting how it affects the quality of the content (versus books authored by persons with expertise in given topics).
I recently read a comment (I think it might have been on HN, but I can't find it) that said something like this: if you recently learned/mastered a topic, you're in a far better position to teach that topic than an expert, who's so deep into it, that they can't understand the beginners.
I wish I could find the source for this, because it was much better put, but that comment contains the gist of my motivation behind writing the book.
This is credible, but I'd guess that it'd be more accurately restated this way: if you recently learned/mastered a topic, you both have a fresh recall of the elements involved in reaching your level of mastery and what was involved in bridging that (personal) gap between unskilled ignorance and that mastery.
Whether that puts one in a far better position to teach than an expert probably depends on the expert. I definitely had math professors for whom the charge applied, and I'd speculate that an expert who's primarily focused on further mastery/development along the edges of the field might be someone who becomes less and less able to recall or relate to what it's like to take first steps into it. But on the other hand, I had math professors who clearly thought a lot about pedagogy as well as research, and practiced both at length... and I think someone who's spent significant time teaching beginners and reflecting on that as well as practicing their discipline and refining deep insights from that is likely in a better position to teach a topic than someone who just learned.
(And if you really want an optimal learning environment, put a class full of motivated learners in front of a teacher like that, and have them talk to each other. Hence the value of a good university course...)
The great benefit of experts over I-just-learned-this authors is that experts know how design x or feature y relates to other designs and features not implemented in the given project.
In other words, they know a lot more context and can tell whether something that appears totally normal in the project is actually done in an unusual way that has limitations, etc.
Completely agree. Currently reading a book authored by the creator of a framework and having a hard time of it. So many newbie questions. There is extra stuff I don't need to know as a beginner - put that in another book or another section. Don't interleave it with the basic material. There is stuff that make assumptions that I am an expert in the language, the code needs to be fully explained, line by line.
This applies to anything that we as human do, including doctors [0]. Younger doctors that are just out of a residency are more up to date about medical science and have the facts in a fresh memory.
> Younger doctors that are just out of a residency are more up to date about medical science and have the facts in a fresh memory.
Perhaps, but they often have not yet built up the muscle memory needed to manipulate instruments as skillfully as more experienced doctors, nor the knowledge needed to know how to handle unusual situations, both of which are particularly important for surgeons[0,1].
> if you recently learned/mastered a topic, you're in a far better position to teach that topic than an expert
That can work, assuming that (1) the particular difficulties you encountered will generalize to most other learners and that (2) being good at programming equates to being good at pedagogy.
>I recently read a comment (I think it might have been on HN, but I can't find it)
> if you recently learned/mastered a topic, you're in a far better position to teach that topic than an expert, who's so deep into it, that they can't understand the beginners.
Most experts I come across are generous when it comes to sharing what they know and their generosity may sometimes get in the way of a beginner's learning, but this is not always the case.
My subjective opinion is that a reader would learn more from a person that went to discover a new topic and wrote down the steps and knowledge acquired along the way. The reader is essentially taking the same steps, learning the same things. If however an expert would write about the same topic, she will have hard time to follow the same pattern.
I believe that J.K. Rowling used the same pattern for her Harry Potter books. She started writing them for children and then each book followed the same kids to their adulthood.
I think it's worse for the reader. Experience gives you "undocumented" knowledge - for example, knowledge of how system behaves under real load and what bottlenecks are and what are other limitations of particular architecture.
I think it's probably both, once you know a subject well it's easy to take some of that knowledge for granted. If you have just learnt it then you probably have a little more empathy for the reader.
I tend not to put those two "kinds" of books in same category. I read them with hope to achieve different goals. They aren't read in the same way, but I think that is normal considering those two types.
I believe it was always the case. I can remember books just like this in the 70's and 80's, teaching one how to write a Pascal interpreter in C, or then a GUI system in Turbo Pascal, for example, which felt very much like this kind of introduction/tutorial to both the language, and the application of the language itself to an interesting component. Is this a Go book or a Monkey/Interpreter book? Its neither, but both.
Author here. Sadly, I can't offer digital+print bundles. I sell the digital version through Gumroad and the paperback through createspace, so I don't have to worry about printing/shipping. That makes it very easy for me to sell a paperback version, but also that much harder to offer discounts or bundles or anything, if you already purchased the eBook.
Cool, asking because the level _past_ the AST walking is where I'm at personally in my learnings. I feel most treatments stop at the AST interpreter step, which is what most people see in school already. I wish there was equally good treatment for everything that comes after that. Type systems, bytecode generation, JIT, optimization phases, etc.
I'm not sure if this is what you're after, since it's not really in book form, but I've learned a lot about advanced language implementation from reading the Rust RFCs [1], especially those relating to MIR. Between the discussion on each PR and the resulting implementation in the actual compiler, it makes some very complicated subjects more relatable than they normally would be. I'm really grateful that so much of Rust's development happens in such an open fashion.
Just got the paperback version - excited to dig into this. Signed up to the mailing list as well. Is there a central place for errata, or will that only be made available as updates to the pdf version?
I have been writing one available at https://github.com/archevel/ghoul it is not finished in any way shape or form. I'm currently rewriting the evaluator to do tail call optimization in my spare time and when that's done I'll work on handling macros.
Yes. 5-6 markdown files, converted to epub, mobi, pdf and html with pandoc. I know there are better workflows, especially in regards to embedding code (my approach was simple copy and paste), but if there's one recommendation I can make it's this one: check out pandoc. It's an amazing tool.
I haven't uploaded the code to Github myself, but as of v1.3 of the book the code is MIT licensed. That means there are a lot of implementations floating around, either copied straight from the book or adapter to another language. Here's the repo of a reader who followed the book closely in Go: https://github.com/RyanBrushett/interpreter
I've been recently writing a web app in Go - I like the libraries and the tools - but when pausing to write a test script in python I immediately realized Go can't be the right tool for regular CRUD websites. Python is a joy, I love dynamic patterns when writing code. Dicts and strings! It flows...
So, yay escape hatches!
At some point it was going to be a pattern (Java + jruby/ola bini's language)...
I'd recommend it.