I'm open for consulting for fall/winter/spring. Databases and query engines are most familiar but I'm also spilling out into compilers. I've had some good gigs lately doing general performance engineering too, and I think testing/fuzzing would also work well.
sql needed structure
I wrote this thing. I regret the tone a little - too much internet brawl. I may rework it later. But I think the core argument is sound.
forum
I've been very fallow the last few months, but I'm finally get rolling again. I still haven't touched zest (but I will!), but I've been working on a little forum project with a friend. We're experimenting with how UX can affect the kind of discussion that is encouraged. We want to make it feel more like having a bunch of interesting pen-pals rather than falling into a sewer full of angry mutants. Community obviously matters most, but the best community can still get drowned in sewage by the wrong incentives. So we've been thinking about ways to tilt the gradient in the right direction:
- Batch updates to the site every 24 hours, so that your comment isn't actively penalized for taking the time to actually read the article and there is also no incentive to doom-refresh. Instead it'll be more like getting the morning newspaper delivered with your coffee.
- No voting or likes. No audience to play to. But maybe we'll have frowns for specific bad behaviours that tend to degrade communties eg "contempt".
- You can only post links to your own writing. So if you want to discuss something else, first you have to read it, digest it, and write down your own thoughts.
- An annual vote for best-of-the-previous-year, to encourage writing posts/comments that provide more than momentary entertainment.
There is one big puzzle for which I don't yet have any ideas. For any given niche, there are far more clueless people than there are experts. So voting systems for comments often result in the clueless outvoting the experts. The most entertaining/satisfying comments rise to the top rather than the correct ones. Removing voting actually improves this somewhat, and active moderation / peer pressure can raise the floor by removing / discouraging the obviously terrible comments. But it doesn't feel like enough.
Context collapse feels like part of the problem. In real conversation, you are talking to a recognizable face with a memorable track record. If they're full of shit then you'll find that out pretty quickly and ignore them in the future. But online communities tend to be much bigger and have fewer cues for memory.
On the Line: Top Rope Solo Manual
I read this and I haven't died yet.
It's really hard to find any reliable information about TRS. There is no equipment standard, so manufacturers are scared that explaining whether or not their equipment is suitable for TRS would expose them to lawsuits. Kudos to Andy for putting his neck on the line to lower other climbers risk.
Much better than the subtitle would have you believe. The author is an anthropologist and marathon runner who spent a year and change training with a running club in Ethiopia. Their approach is built much more around motivation than measurement, maintaining a sense of adventure and working to become 'dangerous'. It was a really timely read for me after burning out hard training with lattice. It also reminded me of the parkour scene in London, which always felt a little mischievous and transgressive. I miss that here.
Sound Gradual Typing is Nominally Alive and Well
The hard part of gradual typing is dealing with the boundaries between typed and untyped code. You want to make sure that runtime type errors can only occur in the untyped code, unlike eg typescript where unsoundness allows even fully typed code to produce runtime type errors.
The traditional way to do this is whenever an untyped value is passed to a typed expression, the compiler inserts code to wrap it in a new value that perfoorms any needed runtime assertions. Eg if you pass an untyped function to an expression with type int -> string then the compiler wraps that function in a new function that asserts the input is an integer and the output is a string.
The big problem with this approach is that if you cross the boundary back and forth you can end up with a lot of nested wrappers and that adds a lot of runtime overhead. Also the wrappers mess with object identity / equality, which can be annoying.
The main contribution of this paper is pages and pages of formalization the observation that you only need wrappers when the value can't be efficiently checked against the type. They design a language where all possible value/type combinations can be checked efficiently, replacing js-style objects with nominally-typed single-inheritance classes, anonymous functions with nominally-typed interfaces, and forgoing generics entirely.
The resulting language is about as expressive as pre-generics java ie not great, but workable. They discuss the challenges of adding generics - in particular issues where removing type annotations can cause runtime type errors. But I think they missed out on julia's solution here, where the instantiation of a generic type parameter is (almost) never determined by type inference. I think this comes from the historical focus on type erasure leading people to think of types as being layered on afterwards, whereas julia started with types (including generics) in the dynamic semantics and then derived type checking from abstract interpretation of those semantics. This is an easy to satisfy the guarantee that removing type annotations can never add runtime type errors, because type annotations are the only source of runtime type errors in julia!
Understanding the Performance of WebAssembly Applications
...via mostly microbenchmarks, with no error bars, no absolute times and no mention of jit warmup. So I have no idea whether the results mean anything.
The abstract mentions llvm optimizations not being tuned for wasm, which I can definitely believe and was what piqued my interest in the paper, but I don't think they substantiate this well at all.
A Snapshot of the Performance of Wasm Backends for Managed Languages
If the results are accurate then the performance of wasmgc backends is disappointing. But still just microbenchmarks and taking the average of 5 runs, so unclear if they were even fully tiered up.
But they also look at the relative effects of different compilation strategies in their own compiler. They find that using relooper over one-big-switch-loop is the only change with dramatic effects, and that doing their own register allocation has marginal benefit over using fresh locals for every ssa variable.
other stuff
Alex Miller made a standalone tutorial and explainer for copy-and-patch compilation. It's much easier to follow than the original papers.
A pypy dev warns cpython jit devs about problems they are going to run into. I've been kind of bearish on the cpython jit so far, and this made me much more so. Especially the data-dependent diverging control flow, which is part of what drove people away from tracing jits in js, and this talk points out that some really basic python idioms like default arguments can cause it.
The wasm spec has a new proposal for an eval primitive. It's not super important for zest, since I compile whole call-graphs at once and so don't pay much per-module overhead, but still worth keeping an eye on.
Kevin Munger points out how the isolation of science from real world results is in part driven by scientific institutions:
Tech startups are allowed and financially encouraged to run uncontrolled “experiments” on hundreds of millions of people. They “try things out” all the time; social media was a massive, poorly-designed experiment, and now they're just letting chatbots rip throughout the most alienated and lonely members of society. They don't aspire to "generalizable knowledge," so they aren't doing "human subjects research," so no ethics review is necessary. The message of the IRB is that the ethical risk of an RCT comes from the addition of a control group to the nihilistic rollout of a massive new social technology.
Alex points out that you can just read your code and look for bugs. I definitely think that my main consulting superpower is actually reading my clients code. Usually codebases are heavily fractured across teams and individuals, few of whom read beyond their own changes. Following the dataflow all the way through multiple teams almost always uncovers bugs or wasted work.