4 ms·

This class of problems falls into a weird space for me. They are 'toy problems' but not I don't feel like I'd have fun doing them. I had a lot of fun playing S

by jblow 10y ago

This class of problems falls into a weird space for me. They are 'toy problems' but not I don't feel like I'd have fun doing them. I had a lot of fun playing Shenzhen I/O and TIS-100, so if you want to do some programming challenges, I'd recommend trying those.

MaulingMonkey 10y ago
I solved the first couple from a previous year's in pure x86 as a means of making them more interesting. A few hundred lines of terrible, terrible x86. I was amused when it performed even worse than expected - thanks to the lack of console buffering when I eschewed linking in the C stdlib (I forget if I instead invoked WriteConsole or what...)
joelgrus 10y ago
Yeah, I made it about 5 days in this year and then quit because I wasn't having fun. Too many of the problems had the structure: * here's Part A * submit solution for Part A * OK, now here's Part B * Part B is just different enough that you have to do a not-fun refactoring of your Part A code (that wouldn't be necessary if you'd just been asked to also design for Part B up front) It was too much like working with an awful PM who can't decide what they want, and it mostly just made me angry.
- steveklabnik 10y ago
  I didn't get that far either, as I got too busy, but that's the part I liked the most about it: did I write my code well enough for part A that I didn't need to do a lot of work for part B? What could I have done differently to make the code resilient to requirements changes?
- tptacek 10y ago
  One way to look at it is that the part-2 problems are un-fun retreads of the part-1 problem. The other (better, I think!) way of looking at it is that the part-2 problems are incentive for you to think carefully about your part-1 solution, so that it generalizes. Norvig's keypad is a perfect example. Norvig's solution of a sentinel character generalizes, as would a solution based on a simple graph structure. But I plowed into it with a flat array of integers and the modulo operator, and had to rewrite for part-2; my solution was, in the context of the contest, inferior to Norvig's.
  - justinhj 10y ago
    I made a graph and it adapted nicely to part 2. An advantage of the graph is that it would have handled the keypad becoming 3 dimensional or some other change that stopped it working as a simple grid. A big disadvantage is I made several errors while building the graph in both parts which took a while to track down.
prezjordan 10y ago
I had a lot of fun with them because of how straightforward they were. I didn't spend any time with pencil and paper like I do with most programming challenges, but instead immediately started writing code in a new language (in this case, Ruby). It was a breath of fresh air from the other problems where I have to do fancy things like "dynamic programming" and "math."

by jblow 10y ago

MaulingMonkey 10y ago

I solved the first couple from a previous year's in pure x86 as a means of making them more interesting. A few hundred lines of terrible, terrible x86. I was amused when it performed even worse than expected - thanks to the lack of console buffering when I eschewed linking in the C stdlib (I forget if I instead invoked WriteConsole or what...)

joelgrus 10y ago

Yeah, I made it about 5 days in this year and then quit because I wasn't having fun. Too many of the problems had the structure: * here's Part A * submit solution for Part A * OK, now here's Part B * Part B is just different enough that you have to do a not-fun refactoring of your Part A code (that wouldn't be necessary if you'd just been asked to also design for Part B up front) It was too much like working with an awful PM who can't decide what they want, and it mostly just made me angry.

steveklabnik 10y ago
I didn't get that far either, as I got too busy, but that's the part I liked the most about it: did I write my code well enough for part A that I didn't need to do a lot of work for part B? What could I have done differently to make the code resilient to requirements changes?
tptacek 10y ago
One way to look at it is that the part-2 problems are un-fun retreads of the part-1 problem. The other (better, I think!) way of looking at it is that the part-2 problems are incentive for you to think carefully about your part-1 solution, so that it generalizes. Norvig's keypad is a perfect example. Norvig's solution of a sentinel character generalizes, as would a solution based on a simple graph structure. But I plowed into it with a flat array of integers and the modulo operator, and had to rewrite for part-2; my solution was, in the context of the contest, inferior to Norvig's.
- justinhj 10y ago
  I made a graph and it adapted nicely to part 2. An advantage of the graph is that it would have handled the keypad becoming 3 dimensional or some other change that stopped it working as a simple grid. A big disadvantage is I made several errors while building the graph in both parts which took a while to track down.

prezjordan 10y ago

I had a lot of fun with them because of how straightforward they were. I didn't spend any time with pencil and paper like I do with most programming challenges, but instead immediately started writing code in a new language (in this case, Ruby). It was a breath of fresh air from the other problems where I have to do fancy things like "dynamic programming" and "math."