Irreal

I’ve written a few times about Vivek Haldar’s Read A Paper videos. They’re vlogs that “read” a seminal paper in Computer Science. They’re really great. If I’ve already read the paper, that particular vlog serves to remind me of the details. If I haven’t read the paper, the vlog familiarizes me with the content and perhaps inspires me to read it on my own. If you don’t like actually reading papers, the series is a painless way to get many of the same benefits you would from reading them.

In a (regular) post, Haldar explains why he is vlogging and what he wants to accomplish. It’s a nice adjunct to the videos themselves. One of the things he said really resonated with me. He has, he says, deep misgivings about popular coverage of technology. We’ve all experienced that. Often, despite knowing better, we’re attracted by some click-baity headline about technology and discover that the story behind it is sensationalized, misrepresents the actual situation, or is flat out wrong. The only solution, Haldar says, is to read the source documents to get the real story.

Of course, that can be hard—or even impossible if it concerns a field of which we have no knowledge—so Haldar is trying to make reading some of the important papers in our field accessible by helping us through them. Dijkstra’s “Go To Statement Considered Harmful” paper is a good example: the advice to avoid gotos has become received wisdom but if you haven’t read the paper you won’t know his arguments and understand when using a goto is appropriate. Haldar’s video on the paper is an easy way to become conversant with Dijkstra’s arguments.

The videos are short and definitely worth watching when you have a few minutes.

Vivek Haldar has been blogging up a storm with his video readings of seminal CS papers. I’ve written about a few of them but there’s lots more. See his blog for an up-to-date list. A recent post was about the paper Global variable considered harmful by Wulf and Shaw.

As suggested by the title, this paper has some connections with Djkistra’s famous paper Go To Statement Considered Harmful. The connections are much deeper than the shared title meme. Both papers argue that the construct they’re deprecating is harmful because it makes it difficult to understand the dynamic structure of a program.

The paper’s main argument is that variables should be scoped as locally as possible. When a function can have side effects—when it can modify variables that aren’t local to the function—the dynamic nature of the program becomes very difficult to understood. This is one of the principal arguments for functional programming. Wulf and Shaw go further, though, arguing for a stricter variable scoping that attempts to isolate the effects a variable change can have to as small an extent as possible. Take a look at Haldar’s video—or read the paper—for the details.

As with the admonition to avoid gotos, the idea that we should avoid global variables has become a sort of catechism that we recite but don’t understand. There are excellent reasons for the precept but if we don’t understand what they are, we can’t know when they don’t apply.

Even though I’m an Uber user, I’ve never thought very much about their IT infrastructure other than to form an (hilariously) simplified mental model of what it probably looks like. It turns out to be a pretty sophisticated operation that has, among other things, a dedicated “Observability Team” that takes care of building and monitoring Uber’s telemetry subsystems. The system gathers fairly fine-grained metrics on what’s happening and these are monitored to spot problems and reveal opportunities to tune the system for better performance.

Wilfred Hughes pointed me to this post by Richard Artoul over at the Uber Engineering blog that tells the story of how after a recent deployment of some updates, the latency for collecting and filing events increased from about 10 seconds to 20 seconds. They reverted the change and went looking for the source of the latency. That turned out to be harder than you’d guess because the obvious strategies, like profiling, failed. Furthermore, the problem only manifested in the production system so they had to debug on the live system rather than one of their testbeds.

What follows is a tale of some impressive engineering and debugging. Even when they located the offending code, it was hard to understand how it was causing the latency. Before they were finished, they even instrumented the Go compiler to help with understanding what was happening. When they were done, they completely understood the problem and had made a change to one of their algorithms to prevent it from happening again.

If you write code, you really should read this post. It’s an example of debugging at its best.