Keep in mind that I specified that this is an optimal solution for this particular map. General solutions are great, but if you have additional information for leverage, you use it. In fact, as stated in explanation of the solution, the solution solves maps which the following precedence preference: Right > Left > Straight. Just FYI, it's not a bug if you understand the limitations of a solution.

General solutions for mazes (graphs really) generally follow a depth, breadth or hybrid approach. I'm actually surprised that all of the general solutions have been depth and none breadth. It's a bit more convoluted in this case as you'd have to traverse backwards, but conceptually, it's no more different than using a FIFO or LIFO.

In any case, with the tools given for this particular "challenge," a general graph search is impossible as you can't record previous states. It's simple to construct a map which causes an infinite loop.

A good analogy of my approach would be using a knowledge based finite state machine over a genetic algorithm or neural net. Is it less elegant? Sure is. However, it's also clearly defining a particular problem / solution pair with certain limitations and expectations.

Then, as I said, "you may as well just hardcode the answer to this one". It takes 15 blocks to hardcode an answer with the optimal solution and almost no time thinking. This solution not only takes 15 blocks to build but executes in exactly that much time.

Alternatively, you can spend a bunch of time proving to yourself that you have a solution that takes advantage of properties of this specific maze that gets you down to 10 blocks. However, as the result now has multiple levels of nesting and is littered with comparisons and jumps, it is going to take more time to execute and get to the end of the maze. I'd even go so far as to claim it is no longer an "optimal solution".

As you said yourself: "yes, elegant code is fantastic, but don't lose track of why we write code in the first place". I can understand spending the time to build something complex if you at least solve the general problem, but to spend more time in development to end up with a slower-to-execute answer that looks like a general solution but isn't seems to fall into your own trap ;P.

You're assuming the fallacy that it takes less time for an explicit solution. The solution took less than 2 minutes and most of that time was spent trying to figure out how to manipulate the puzzle pieces. Now if you're talking execution time, yes conditionals and loops add to the complexity of the execution, but for any non-trivial graph, the implementation time of a non-pattern recognizing solution would be much greater.

In any case, the points I'm trying to make are simple:

1) Solid program execution is much more important than line reduction.

2) Defining a problem space / limitations allows for better code / reuse.

3) When the implementation trade off is sufficiently small, it's better to increase the scope of the solution for possible reuse.