Greetings from surprisingly sunny Portland, Oregon:
I have one new publication and one new draft paper to announce!
This post is the second in a series. Last time, we started coding up a toy interpreter for a language of arithmetic expressions. This time, we’ll extend the language to include variables and update our interpreter to handle that extended language.
I spent last week volunteering as a resident at Hacker School, where I helped a number of students write small interpreters. For the most part, the students I worked with weren’t exactly beginning programmers. One of them, for instance, was a robotics Ph.D. student who had written a trajectory follower that helped a robot autonomously navigate through the desert.
Clearly, it’s possible to get quite far in a programming career without having written an interpreter — or, at least, without having consciously done so. So, why does it matter? Why should you write an interpreter?
I’ve written a few posts about my work on LVars, which are data structures that support deterministic multithreaded computation. Fundamentally, there are two things to do with an LVar: write to it, and read from it.
When I talk about how LVars work, I usually focus on writes, but they’re only half the story. In this post, we’ll look at how LVar reads work.
Hacker School is a project-based, self-directed, immersive three-month school in New York for becoming a better programmer. The idea of Hacker School has appealed to me since I first heard of it a bit over a year ago, and the more I’ve learned about it since, the bigger a fan I’ve become.