I like powerful languages without a too many built in convenience features. That way I get to enjoy solving the problems myself without too much effort.
Some of the solutions are quick and dirty, mostly dirty. And that's not art, but programming kitsch.
It is what you make it.
I admire the ability to brute force problems using the most convenient features available as much as anyone, especially professionally.
But to me, this is about evolving as a programmer; I do enough duct taping at work.
I'm sorry I'm not familiar with the mathematics behind regular expressions. Can you give an example of what your approach would look like?
first = line.match( /(?:(0|zero)|(1|one) ... (9|nine))/) last = line.match(/.*(?:(0|zero)|(1|one) ... (9|nine))/) indexOfGroupMatched = ([_, ...groups]) => groups.findIndex(x => x != undefined) num = +[first, last].map(indexOfGroupMatched).join('')
Oh I understand. That's a good idea. Honestly I only ever use regex for AOC so I never would've thought of using it like that. I'll keep it in mind. Thanks!
Not necessarily. But it's complicated. See: https://docs.rs/regex/latest/regex/#untrusted-input One of the key advantages of a regex engine based on finite automata is that it lets you make guarantees about the runtime performance of a search.
Okay, let me amend my comment. If you have a degree in CS, you're absolutely sure that you've understood all the caveats of the libraries you're using, and you limit your inputs so that the expected running time is under your target execution time, then you can avoid putting a timeout on your regex executions. In any other case, add a timeout.
I certainly wouldn't agree with that at all. And I don't see what a "degree in CS" has to do with anything.
Seems to me that people made part 2 harder than it us. Just define an array containing the digits: "one", "two", and so forth. Then check for substring matches, position by position. Maybe not elegant, but effective.
I think the issue is that they tried to separate the input into a list of tokens, like ["5", "nine"], and work from there, which doesn't work on something like "oneight".
I didn't have that issue at all; I just looped through the 20 different tokens and found first and last instances of all of them, and compared the very first and very last of all instances.
I don't know if I'll even bother this year. Their puzzles start feeling like chores by the 10th problem or so and I drop out. Maybe I'll learn a new language to spice it up this year.
> Their puzzles start feeling like chores
Advent of chore ? :)
..though I agree - never went past 10th day or so.
I think the edge cases were entirely unclear in day 1, part 2. I had to redo it in a "dumb"/brute-force way to avoid using fancy regex tricks I don't know. It's quite clear the small sample data was chosen intentionally to not cover them.
The problem statement was super clear though. "Find the first occurrence of any one of these strings in a longer string" doesn't require any fancy regex tricks, just a for loop and knowledge about `isPrefixOf` or `startsWith` or whatever the equivalent function is called in your language of choice. "Find the last occurrence of any one of these strings in a longer string" is just the first problem again but with all t…
Disagree that it's clear. If the text is "oneight", there is a legitimate philosophical question about whether the string contains two numbers. I feel like most people would say no, because the only way to answer yes is by re-using letters between different words, and that's not how language works.
The only problem with these kinds of languages is finding the place where the experts publish their solutions, if they do. I'd love to see what an expert can do and what I can learn from them.
Man, this feels like a frustratingly good way to get back into Haskell, and on the cutting edge of GHC to boot… Or should I take the plunge and do it in rust? (If only I was unemployed and could do this in agda/idris/lean…)
I did 2016 in Haskell and 2018 in Rust. Haskell was kind of a pain since I had to do a ton of tail recursion. Rust would be a lot easier since it allows you to be imperative when you need to.
And I definitely only used a tiny subset of either language because I wanted to get the solution as quickly as possible.