Here's a puzzle. Without looking at the body, what does this Rust function do?
fn mystery<T>(a: T) -> T
If you know a little type theory, you might already see it: this function must return a. Not by convention, nor by style guide: the type system makes any other implementation impossible. There is nothing else you can do with a value of an unknown type except give it back.
This property—that a type signature can determine an implementation—is called parametricity, and it's one of the most underappreciated ideas in programming language design. It's also exactly what Zig's comptime gives up.
Over the Christmas holidays I decided to learn more about OxCaml, Jane Street's systems programming variant of the OCaml programming language. In this post I give an overview of OxCaml, describe how to get started using it, and discuss a simple example that shows the performance benefits from using one of its basic feature: unboxed types.
Of my recent projects, one of the most fun was creating an algorithm for generating unique identifiers. In this post I'll walk through my process, and show how a combination of mathematics, computer science, and business requirements lead to the solution. I found this a very interesting problem, and I think it makes a great case study of how theory and practice go together.
We recently wrapped up season six of ScalaBridge, with a review of the past season and a discussion of what we want to see next year. To be honest, entering the review I wasn't feeling optimistic about ScalaBridge's future. In the two years since resuming I feel we haven't found a structure that really works. Partly this is the environment we're in; everything is harder now than it was before COVID. However, I still feel we're failing to deliver what the people want, which is most clearly reflected in our high dropout rate. I left the review in a completely different mood, excited for the future. In this post I'm talking about the changes that we're looking to implement, and how we're going to do it. I've distilled the feedback into three interconnected themes, content, community, and connection, which I discuss below.
When understanding programming language features, and explaining them to others, I've found it useful to have two different kinds of explanations. The first kind, which I call an operational explanation, explains a feature in terms of how the program executes. The second kind, which I call a denotational explanation, explains features in terms of what they mean to the programmer. For myself, and those I teach, it's usually easier to start with an operational explanation. However, I find denotational explanations more useful in the long term.