Advent of Code 2021 - Day 14

MononcQc · December 14, 2021, 2:37pm

The experience of doing it with a non-functional language for the first time really highlights to me how much more trouble a lot of these implementations would be with immutable data structures, mostly because you have to more carefully pick your data structures and orient them towards one type of solutions.

Here with awk it’s just “am I gonna use strings and regexes, or just some arrays and loops?” and the array+loop approach is right pretty much every time, to an extent that is sort of ridiculous. I can imagine doing today in Erlang using some sort of sequences, maps, or whatever, and a slight variation in the second part just throws that basic data structure out and needs to re-shape the whole solution, in ways that wouldn’t be the case if you had the spec for both parts early on.

github.com

ferd/advent-of-code-2021/blob/main/day14.awk

# each rule is there only once, so we can use an array to count changes. If
# we have the string NNCB, and NN --> V, then a[NN]-- and a[NV]++ and a[VN]++.
BEGIN { FS="" }
NR==1 {
    for (i=1; i<=NF; i++) { acc[$i]++ }
    for (i=2; i<=NF; i++) { a[$(i-1) $i]++ }
}
NR==2 { FS=" " }
/->/ { rule[$1]=$3 }

END {
    for (i=1; i<=40; i++) {
        copy(a, b)
        for (r in rule) {
            matches = a[r]
            if(matches > 0) {
                split(r, parts, "")
                b[r]-=matches
                b[parts[1] rule[r]]+=matches
                b[rule[r] parts[2]]+=matches

This file has been truncated. show original

Anyway, I don’t know if that’s a parable for functional programming as a whole; the optimizations you need to take something inherently mutable and making it immutable tend to lock you down a bit deeper than otherwise. That being said, whenever a problem calls for recursion (graphs and searches) it’s ridiculous how much simpler this all is with Erlang though.