Crafting “Crafting Interpreters”

> I make mistakes sometimes, usually when lettering like “upvaluels” here. I fix that in Photoshop after scanning.

That's a pro tip, right there. All too often I get caught up in using the tool/program I'm in to do something completely, where it causes inefficient work loops. Part of that is realizing I'm stuck in a loop in my mind, and need to expand my horizons. Familiarity lets you know when to abandon one approach and use another (or at least when and where to shave off the rough bits you're subjecting yourself too). As an example, this doesn't happen to be in the shell. I'll happily take any textual output I'm given and process it through one or more tools to manipulate it, or if it comes to it, write a Perl one liner (or even convert that to a small Perl program with better syntax if it gets more complex) to manipulate and massage data, even if the purpose it to throw it back into the same program.

That may or may not be the most efficient way to tackle the problem, but it's a known solution, as opposed to not only not knowing how to to it in the tool I was using initially, but not knowing how to efficiently determine if it can even be done in that tool.

In this case, he's using pen and paper. He makes a mistake in the lettering after making sure the rest of the structure is correct, so he's got 90% of it correct and to his liking. He can start from scratch which is time consuming, or use some other physical medium tools (like white-out) to fix it, but it may not look quite right, or he can annotate the error with the fix and he can use a separate tool designed for quick and accurate visual manipulation (as opposed to creation, which it does but for many not as easily as with pen and paper) and layer a very effective fix in place afterwards.

Recognizing where and when you can do this effectively is likely one of the most beneficial skills you can train. It comes naturally with experience in an area, but being able to apply it to almost anything you do is a skill in itself.

I currently use parts of the textbook Programming Language Pragmatics [1], one of the semi-standard texts used by a lot of universities (plus some of my own course notes). That book isn't really readable straight through though. It's 992 pages long, and some of the chapters get bogged down in a ton of coverage of the landscape of design and implementation choices. As a reference book that has some pros: you can look up something like looping constructs, and get a very detailed tour of how languages from Algol-68 through Modula-2 and C# have taken different design and implementation strategies. But that's not the same as reading something as your first introduction to a subject.

[1] https://www.cs.rochester.edu/~scott/pragmatics/

I was caught in that loop with the first couple of chapters where I felt like the drawing itself had to be perfect and I would redraw them if I made a mistake. I got wrapped up in some sort of purist ideal (an affliction I am highly susceptible to).

Eventually I realized that all that matters is the final image, so I got better about taking advantage of Photoshop. Each line and letter in the diagram was still drawn by hand on paper, but sometimes I rearrange or fix mistakes in Photoshop.

> that's an opportunity cost of 200k*

Yes, there's definitely a financial opportunity cost. But when I see someone working a job they hate eight hours a day, I often wonder what the satisfaction opportunity cost of that is. What could they be doing instead that would be more meaningful to them?

I'm unlikely to make enough money from the book to justify the time (though my first book made me much more than I expected), but I do think it will bring enough other rewards to be worth the time.