Over the years, I have worked on a number of projects. This page gives a quick overview.


My reimplementation of Sokoban, the classic puzzle game, was driven by necessity. I had previously had a lot of fun with KSokoban, KDE's Sokoban implementation. That, however, was only available up to and including KDE 3 which has long been deprecated. After considering porting KSokoban to a newer version of KDE, I decided against it. Working with C++ is much less fun than writing Go code. So I implemented the core of Sokoban, i.e. data structures to store the current state of the game and functions to manipulate it. The result was a small programme that could read a list of moves encoded as a string (using u, d, l, r for up, down, left, right) and try to perform those moves in a given level. At this point, my attention shifted to different projects.

At some point, I stumbled upon QMLSokoban, a QtQuick-based implementation of Sokoban using KSokoban's level sets and graphics. I added some more advanced features of KSokoban in QMLSokoban, for example left-clicking to move have the worker walk to the clicked position, if it is possible to do so without moving any boxes, or right-clicking to move in a straight line towards that position, pushing crates if necessary. To problem was, QMLSokoban was meant to animate each step, one per user input, individually. It was not designed to handle a sequence of moves triggered by a single click, so the worker just moved in a straight line from its original position to the target instead of moving just left, right, up, or down.

Instead of rewriting QMLSokoban to accommodate such multi-step animations, I decided to eschew Qt altogether and writing a new implementation of Sokoban from scratch. At the time, I used more and more Rust, so it was the obvious language to choose.

After experimenting with Conrod, I came to the conclusion that it was needlessly complex for what I wanted to do. So I went with just OpenGL via the excellent Glium.

My Sokoban clone now supports not only path finding, but has a macro system, saves state on disk, specifically, which levels you have already solved, how many moves/pushes you used, and even what those moves were. It also animates moves triggered by macros or mouse clicks properly and adjusts the animation speed if there are many movements left to show.


Alexandria is a programme for managing mathematical knowledge. It is named after the Royal Library of Alexandria, which had one of the largest collections of mathematical knowledge of its time.

Alexandria manages a collection of files, each of which contains one theorem, lemma, definition, remark, example, etc. The content of those files is indexed using Bleve.

There are also some older versions of Alexandria: as a Haskell library with a separate command line interface and an unpublished version written in Racket.


As part of a small group (six people) I worked on Alvis, a tool for visualising algorithms. In particular, I designed a very simple imperative programming language that is used to describe the algorithms one wants to visualise. In addition, I created a compiler using ANTLR 3 that reads code in this custom language and emits corresponding Java code, which is then passed to the Java compiler and executed.

LLVM Backend for OCaml

Inspired by the LLVM backend for GHC (the Glasgow Haskell compiler), my bachelor's thesis in informatics was about implementing such a backend for OCaml.

LLVM and Haskell are a much better match than LLVM and OCaml. LLVM needs to be patched to support OCaml's custom calling convention. In addition, neither Haskell, nor OCaml use any of the return conventions implemented in LLVM. Since Haskell programmes are transformed into continuation passing style, no Haskell call ever returns, so that is no problem at all. OCaml calls do, however, return. Also, Haskell uses C++ exceptions, which LLVM provides, while OCaml uses a custom way of handling exceptions that no other programming language uses. It turns out that this way of handling exceptions cannot be easily implemented in LLVM.

In short: OCaml and LLVM don't go together and the backend only ever properly worked for the simplest of programmes.


For my own use, working as a teaching assistant at university, I created a programme to analyse students assignment results: Plotting how many students got what score on each of the individual assignments handed in per week, how many students handed in anything, how their results in the weekly assignments compared to exam results, things like that. I have since become somewhat disillusioned of Julia. The frequent braking changes to the language, often with little documentation on how to replace a deprecated feature, sometimes third-party dependencies that do not work with the current version, can certainly be annoying. What really got me going is that the Julia developers seemed to care little about correctness. Dan Luu's post nicely sums it up.