From personal experience, I can attest that maintaining compiler infrastructure that builds on top of LLVM is hard over the long term. You try to compile something from a year ago with newest LLVM and find that it no longer works. The upstream LLVM developers make breaking API changes and it is the responsibility of downstream clients to fix their code accordingly.

I can only imagine the joys of keeping up with the JavaScript frontend and npm ecosystems, having mostly avoided that fun. A few months ago, I did get hit with a breaking Hugo update.

In this essay, we make a broader argument: there are opportunities in analyzing changes to software components and either certifying compatibility or detecting breaking changes. Furthermore, many programming languages techniques (formal verification through testing and of course programming language design) can contribute to the important problem of reasoning about upgrades. We survey the role of contracts and discuss how to best determine the exposed API surface of a component.

Spring in New Zealand

Once again, spent two-thirds of this month in Wellington. The other 10 days were around Christchurch and Kaikoura. Currently no trips planned until November 27, although perhaps Auckland for not-Nationals judo tournament in early November.

We are moving 700m down the street tomorrow though. The lease on our current place ended and so we looked around for alternatives (although a fun fact is that, like in Ontario, a fixed-term lease automatically becomes periodic upon completion in NZ and needs to be explicitly non-renewed 21 days before the end date). The new place should be nicer in many ways although the view might not be as good.

In Wellington. Previous trip: Stewart Island; returned to Wellington August 11 (a day before New Zealand went back up to level 2 and Auckland to level 3 following discovery of a new cluster). Next trip: Christchurch, September 11, originally for the South Islands judo championships, now cancelled (oops).

Aside from that, it’s been a fairly quiet month. I hope to at least get all of the Heaphy trip posted and maybe some of the Rakiura trip before going to Christchurch in two weeks. Booked Kepler, Milford, and Routeburn tracks for later this year.

I’m between trips as I write this. Tomorrow morning we are flying to Invercargill at the end of the South Island and, if weather permits, continuing to Stewart Island/Rakiura. (I’ve learned, however, that we often need to be flexible with these plans, as weather can be from slightly to extremely unfavourable.) Two and a half weeks ago we came back from Christchurch and the West Coast.

I noticed that I promised a writeup for Charleston last month. It’s still to come. The backlog continues to increase.

tl;dr: Sabbaticals are not an unpaid vacation but rather a chance to focus on longer-term scholarly projects.

Sabbaticals are an awesome feature of the academic job. I feel like they are often misunderstood by the world in general. This description is specifically about how sabbaticals work at the University of Waterloo; many North American universities are similar but not identical.

The normal distribution of work for tenure-track and tenured faculty members at the University of Waterloo is 40% teaching, 40% research, and 20% service. In my department, Electrical and Computer Engineering, 40% teaching means 3 one-semester courses per year: typically one term with 2 courses, one with 1 course, and one with no courses. For regular faculty members, service involves sitting on and chairing university committees (internal service), as well as participating in a research community by reviewing papers and being on committees (external service).