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.
In this post we'll build a DSL for terminal interaction. The terminal is familiar to most programmers, and terminal applications are common for developer focused tools. Most terminal features are controlled by writing specially formatted text. However, applications benefit from higher-level abstractions, motivating libraries that present a more ergonomic interface. Our implementation will showcase codata interpreters, monads, and the central role of designing for composition and reasoning.