Irregularly Scheduled Programming

In the lead up to Christmas each year, Advent of Code offers a series of 25 puzzles which start out reasonably simple, but get progressively harder, eventually requiring knowledge of algorithms and dynamic programming techniques. Last year I solved these in (strictly) base R on the day they were released (or as close to as I could). I then (starting Dec 27) went back and re-solved (13 of) them in Rust.

This post details what I learned along the way and some fun visualisations I made.

Print debugging has its place. Sure, it’s not always the best way to debug something, but it can often be the fastest. In this post I describe a useful way to do this in Rust and how we can get similar behaviour in R.

If you’re reading this hoping that I’m done with droning on about array-languages, close the tab… it only gets worse from here. If you thought APL was unreadable, even after my earlier blog posts, again - close button is right there. In this post I try out a brand new stack-based array language and continue to advocate for learning such things.

I’m part of a local Functional Programming Meetup group which hosts talks, but also coordinates social meetings where we discuss all sorts of FP-related topics including Haskell and other languages. We’ve started running challenges where we all solve a given problem in a language of our choosing then discuss over drinks how they compare.

I keep hearing the assertion that “writing APL/Haskell/etc… makes you think differently” and I kept wondering why I agreed with the statement but at the same time didn’t think too much of it. I believe I’ve figured out that it’s because I happened to have been using Array-aware languages this whole time! It turns out R is an even better language for beginners than I thought.

One thing that has really caught my attention as I learn more programming languages is the idea of generators or infinite sequences of values. Yes, infinite. Coming from R, that seems unlikely, but in at least several other languages, it’s entirely possible thanks to iterators and lazy evaluation.

I’ve been learning at least one new programming language per month through Exercism and the #12in23 challenge. I’ve keep saying, every time you learn a new language, you learn something about all the others you know. Plus, once you know \(N\) languages, the \(N+1^{\rm th}\) is significantly easier. This post covers a calculation I came across in Haskell, and how I can now do the same in a lot of other languages - and perhaps can’t as easily in others.

Your collaborator says to you “I have some code I’d like to distribute to people who will probably work in R most of the time. I don’t write R, but I write C. Can you package this up for me?” so you have a few options: re-write the code in R, package up the C code and make it available in R, or say no. I decided to try out the second of these, and this post details how I achieved that.

With Functional Programming, we write functions which take arguments and do something with or based on those arguments. You might not think there’s much to learn about given that tiny description of “an argument to a function” but the syntax and mechanics of different languages is actually widely variable and intricate.

I’ve been learning at least one new programming language a month through Exercism which has been really fun and interesting. I frequently say that “every language you learn teaches you something about all the others you know” and with nearly a dozen under my belt so far I’m starting to worry about the combinatorics of that statement.

APL isn’t on the list of languages but I’ve seen it in codegolf solutions often enough that it seemed worth a look.