“Wenniger aber besser”
— Dieter Rams {:.big-quote}
I can barely believe it’s a full year since I published my intentions for 2018. A lot has happened since then. Principally: in November I started a new job as Data Services Lead at The British Library. One thing that hasn’t changed is my tendency to try to do too much, so this year I’m going to try and focus on a single intention, a translation of designer Dieter Rams’ famous quote above: Less, but better.
Python is great, but I find it useful to have an alternative language under my belt for occasions when no amount of Pythonic cleverness will make some bit of code run fast enough. One of my main reasons for wanting to learn Rust was to have something better than C for that.
Not only does Rust have all sorts of advantages that make it a good choice for code that needs to run fast and correctly, it’s also got a couple of rather nice crates (libraries) that make interfacing with Python a lot nicer.
I’ve chosen not to make any specific resolutions this year; I’ve found that they just don’t work for me. Like many people, all I get is a sense of guilt when I inevitably fail to live up to the expectations I set myself at the start of the year. However, I have set a couple of what I’m referring to as “themes” for the year: touchstones that I’ll aim to refer to when setting priorities or just feeling a bit overwhelmed or lacking in direction.
!!! tldr “TL;DR” I’ve made Saga, a thing for compiling documents by combining code and data with templates.
Saga is a very simple command-line tool that reads in one or more data files, runs one or more scripts, then passes the results into a template to produce a final output document. It enables you to maintain a clean separation between data, logic and presentation and produce data-based documents that can easily be updated. That allows the flow of data through the document to be easily understood, a cornerstone of reproducible analysis.
When you’re writing analysis code, Python (or R, or JavaScript, or …) is usually the right choice. These high-level languages are set up to make you as productive as possible, and common tasks like array manipulation have been well optimised. However, sometimes you just can’t get enough speed and need to turn to a lower-level compiled language. Often that will be C, C++ or Fortran, but I thought I’d do a short post on why I think you should consider Rust.
Trees reflected in a lake Joshua Reddekopp on Unsplash
It seems like ages ago, but way back in November I committed to completing Advent of Code. I managed it all, and it was fun!
All of my code is available on GitHub if you’re interested in seeing what I did, and I managed to get out a blog post for every one with a bit more commentary, which you can see in the series list above.
Today’s challenge, takes us back to a bit of computing history: a good old-fashioned Turing Machine.
!!! commentary Today’s challenge was a nice bit of nostalgia, taking me back to my university days learning about the theory of computing. Turing Machines are a classic bit of computing theory, and are provably able to compute any value that is possible to compute: a value is computable if and only if a Turing Machine can be written that computes it (though in practice anything non-trivial is mind-bendingly hard to write as a TM).
Today’s challenge, the penultimate, requires us to build a bridge capable of reaching across to the CPU, our final destination.
!!! commentary
We have a finite number of components that fit together in a restricted way from which to build a bridge, and we have to work out both the strongest and the longest bridge we can build. The most obvious way to do this is to recursively build every possible bridge and select the best, but that’s an O(n!) algorithm that could blow up quickly, so might as well go with a nice fast language! Might have to try this in Haskell too, because it’s the type of algorithm that lends itself naturally to a pure functional approach.
Today’s challenge requires us to understand why a coprocessor is working so hard to perform an apparently simple calculation.
!!! commentary
Today’s problem is based on an assembly-like language very similar to day 18, so I went back and adapted my code from that, which works well for the first part. I’ve also incorporated some advice from /r/haskell, and cleaned up all warnings shown by the -Wall compiler flag and the hlint tool.
Today’s challenge has us helping to clean up (or spread, I can’t really tell) an infection of the “sporifica” virus.
!!! commentary I thought I’d have another play with Rust, as its Haskell-like features resonate with me at the moment. I struggled quite a lot with the Rust concepts of ownership and borrowing, and this is a cleaned-up version of the code based on some good advice from the folks on /r/rust.