It's a good idea to set expectations about what you want to achieve. If you're publishing puzzles that you expect people to solve in their head and you know it's uncommon, you'll avoid lots of criticism / confusion by stating that upfront. ("Some of you may be surprised with the format, but the trick here is to solve the puzzle in your head without external tools.") Other services with programming challenges normally give you sample input/output, so that's a popular expectation in this area. People usually don't stare at the code until they see a solution (as you can see from the comments), since it's not an everyday development scenario.
I'd say that when we read code we read it in a similar way as text. I know what you mean, even if you make tiny mistakes / typos. And that's especially true in the book, where the code is normally prefixed by explanation of what it should do and is there for an extra illustration of the idea, not to be actually executed. Even more: the code in the book can omit required parts or be broken and still serve a purpose. Example:
foo = some text
for h in (itearte over foo indexes]:
foo(h] is now (uppercase foo*h*)
That's totally broken, with typos, and not written in any real language, but we both have the same expectation of what it's supposed to do.
But that works against solving this puzzle in my head. I'm not reading the code to understand it anymore. You explained what it should do and presented the code. I understand it. Instead I need to play the role of "spot the typo" symbolic executor / debugger in my head, which is very different.
He's not trying to sell something, so why should he pretend all feedback is equally valuable? A hobbyist can afford to forego the "customer is always right" mentality.
You can't understand a small block of code without running it in a debugger?
When you read code in a book, how do you understand it?