Hacker News Reader

Comment by eterm | Hacker News Reader

Warning: post contains spoilers, HN doesn't support spoiler text so continue reading at your peril.

These edge cases are triggered by fundamentally approaching the problem incorrectly.

In some ways it's excellent to bring that up early in a way that's relatively easy to debug and diagnose.

Like many others I started with the wrong solution, and I was hit by the same problematic cases, but what I found interesting was that some developers went further down a rabbit hole of trying to force replacement to work (e.g. replacing "one" with "one1one", etc) rather than taking a step back and re-thinking the approach entirely and thinking about the problem as a searching problem.

View on HN

Further spoiler: I replaced "one" with "o1e", "two" with "t2o", etc. which is hacky as hell, but works for throwaway contest code. (Replacing as suggested above also works, but is more typing.)

That let me keep the problem in the filter/map/first-last/reduce space, which was the shape of my solution to part 1.

That’s exactly what I pivoted to once I realized my naive replace wouldn’t work. That sort of moment is what makes AoC feel so rewarding in my opinion.

impl fully showing the trick: https://github.com/rileymichael/aoc-2023/blob/master/src/mai...

I have to say that this is a hacky approach but I love it!

Here's a snippet of a first attempt, which does not work:

  |> Array.map (fun s -> Regex(@"(one|two|three|four|five|six|seven|eight|nine|\d)").Matches(s))
  |> Array.map (fun m -> m |> Seq.map (fun g -> g.Value) |> Seq.toList)

And here's the correct code:

  |> Array.map (fun s -> Regex(@"(?=(one|two|three|four|five|six|seven|eight|nine|\d))").Matches(s))
  |> Array.map (fun m -> m |> Seq.map (fun g -> g.Groups.[1].Value) |> Seq.toList)

There's no "fundamental" difference between the two, rather, one uses a regex with positive lookahead and the other doesn't. The first approach was not operating under the assumption that there would be strings like "oneighth" at the end of a line. That's a detail and it only applies to one part of a functional pipeline!

I agree that one should take a step back at that point but how exactly is this the fundamentally wrong approach to the problem?

Re-using the existing code where possible is the fundamentally right approach to the problem. It just so happens that in this case, there were edge cases that prevented this, so another approach had to be taken.

> Re-using the existing code where possible is the fundamentally right approach to the problem.

Reusing code does not make something "fundamentally right approach". An implementation that actually does what the problem asks is a "fundamentally right approach". If you can reuse existing code in that implementation then that's a bonus.

The problem is very clearly specified, so if you choose to implement something else hoping that it's "close enough" then that's on you...

Wasn't this more about reusing the regex?

I mean, who said you had to use a regex to begin with?

> These edge cases are triggered by fundamentally approaching the problem incorrectly.

That's a bit like you are holding the phone wrong kind of statement. These are just coding exercises, not actual business problems.

In my experience they are very much "actual business problems"-alike situations.

There's never been a customer that asked me "I have some elves that need to make snow and here's a trebuchet", sure. But they ask me stuff, I intepret that as well as I can. Go back for questions. Apply DDD, event-storming or whatever if I'm lucky.

But there always is an interpretation issue somewhere, that makes that some "bug" is really "but I spend 5 hours implementing that exception and now you tell me it's a bug?".

Reply on news.ycombinator.com