After reading the book The AWK Programming Language (recommended!), I was planning to try AWK out on this year’s Advent of Code. Having some time off from work this week, I tried to implement one of the problems in it to get some practice, set up my tooling, see how hard AWK would be, and… I found I’m FP-pilled.
I knew I’m addicted to the combination of algebraic data types (tagged unions) and exhaustive pattern matching, but what got me this time was immutability, lexical scope and the basic human right of being allowed to return arrays from functions.
Part 1 of the Advent of Code problem was easy enough, but for part 2 (basically a shortest path search with a twist, to not spoil too much), I found myself unable to switch from my usual functional BFS approach to something mutable, and ended up trying to implement my functional approach in AWK.
It got hairy very fast: I needed to implement:
hashing of strings and 2D arrays (by piping to md5sum )
) a global set array of seen states
array of seen states a way to serialize and deserialize a 2D array to/from a string
and a few associative arrays for retrieving this serialized array by its hash.
I was very lost by the time I had all this; I spent hours just solving what felt like accidental complexity; things that I’d take for granted in more modern languages.
Now, I know nobody said AWK is modern, or functional, or that it promises any convenience for anything other than one-liners and basic scripts that fit under a handful of lines. I don’t want to sound like I expect AWK to do any of this; I knew I was stretching the tool when going in. But I couldn’t shake the feeling that there’s a beautiful AWK-like language within reach, an iteration on the AWK design (the pattern-action way of thinking is beautiful) that also gives us a few of the things programming language designers have learnt over the 48 years since AWK was born.
... continue reading