I wonder why nearly all the solutions do String.split/2 when we can directly pattern-match strings

  defp d2_destination_reducer("forward " <> value, acc),
    do: %{acc | h: acc.h + String.to_integer(value)}

  defp d2_destination_reducer("down " <> value, acc),
    do: %{acc | v: acc.v + String.to_integer(value)}

  defp d2_destination_reducer("up " <> value, acc),
    do: %{acc | v: acc.v - String.to_integer(value)}

  defp d2_destination_reducer(_, acc), do: acc

In Part 1, you could’ve used Tuple.product and get rid of that then ? I was contemplating on representing my data structure as tuple only so that I could use Tuple.product - one of my favourite functions but since I was in a noisy room, I made the representation more verbose so I don’t mentally keep track of the which position means what.

Clever way to represent the positions though!

My LiveBook:

Day 2

Load input

We do parsing there, as it will help us with the latter tasks. Pattern matching
is the simplest approach there, as input is in form of:

forward 10
up 20
down 30

We need to trim/1 input to make sure that the last newline will not interrupt
String.to_integer/1 calls.

stream =
  File.stream!("day2.txt")
  |> Stream.map(fn input ->
    case String.trim(input) do
      "forward " <> n -> {:forward, String.to_integer(n)}
      "up " <> n -> {:up, String.to_integer(n)}
      "down " <> n -> {:down, String.to_integer(n)}
    end
  end)

Task 1

{h, d} =
  stream
  |> Enum.reduce({0, 0}, fn
    {:forward, n}, {h, d} -> {h + n, d}
    {:up, n}, {h, d} -> {h, d - n}
    {:down, n}, {h, d} -> {h, d + n}
  end)

h * d

Task 2

{h, d, _} =
  stream
  |> Enum.reduce({0, 0, 0}, fn
    {:forward, n}, {h, d, a} -> {h + n, d + a * n, a}
    {:up, n}, {h, d, a} -> {h, d, a - n}
    {:down, n}, {h, d, a} -> {h, d, a + n}
  end)

h * d