Simon Tatham

> no commonly used high level language supports the coroutine call primitive

Shows how old this post is. In fact I remember reading it well over 10 years ago, maybe more like 20. archive.org says that it's at least as old as 2001. A great article.

I'm very excited to see he's published a new article on C++20 coroutines. I've read (or maybe skimmed...) a few introductions and not really got them, despite having used C# and Python coroutines a lot with no problems (even making changes to an async runtime for Python). Given how clear his C coroutine article is, I'm optimistic about the C++ article.

> So, after the course, I went away and studied on my own, and wrote the introduction to C++ coroutines that I’d have liked to see.

https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/coroutines-c++20/

Yeah, I liked how he realized two possibilities for a number that were next to each other, also meant the box around it could be cleared.

I really enjoy finding patterns like these in constraint games. After confirming the pattern for myself a number of times, the brain later just does it on autopilot. If people have tips for similar games I would be happy to try them.

Edit, my tips: Simon Tatham's Puzzle Collection [0] has lots of them. Apps exists for mobile devices as well.
Everett Caser [1] also have lots of logic games where one can learn patterns. I've played Sherlock and Honeycomb, and my favorite is Willa's Walk. They look a bit funky, but the apps work fine on Android.

[0]: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
[1]: http://www.kaser.com/ww.html

Yes. I've always bemoaned the fact that people's first experience with the game is the one bundled in Windows. Because the player knows the game sometimes requires guessing, they never learn which situations actually require guessing and which are actually solvable; they just decide they need to guess because there is no number surrounded by the same number of empty squares, and never discover the math about possibilities that the game requires.

I used to play a version that was guaranteed to never require guessing [1], but it was still possible to accidentally make an unnecessary guess and not be punished for it. TFA's variant is a great way to fix that problem.

[1]: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/ "Mines"

It's also available in HTML/js/wasm, so practically all networked devices:

https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/mines.html

However, the minesweeper puzzle is the one that causes a big wart in the API, which part of me has wanted to refactor for years. (it's for the reason given in GP comment, the puzzle isn't generated until first click; it's the only one with this behavior and could be reworked to have the clicked area be a parameter to creation, but then it would have a slightly quirky main()-equivalent function.. IMO worth it for the cleaner API)

Simon's puzzles have overall been an inspiration, some good reading if you're into algorithms and applied graph theory and don't mind that it's in C.

Was it this one? https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/untangle.html

I went and found this game again relatively recently. It reminds me so much of decoupling and refactoring software or vice versa. I spent a few years occasionally trying to remember what distant memory of an experience decoupling reminded me of.

I quite enjoy both. Whilst simultaneously kind of hating the process.

Incredible sense of clarity once you've resolved everything that was stepping in the way of understanding. Moments of despair and frustration. Sense of progress combined with feeling this could be never ending. Iteratively trying to step towards something better.
It all seeming worth it in the end. So many parallels.

Great js implementation! I don't have any iThing but I'd happily play your js version in a browser for a while.

Since you mentioned Simon Tatham puzzles there's a js version here[1], but it really just isn't quite as good

[1] https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/pattern.html

(if I were to nitpick, for large grids one might want to make the separating line a bit thicker every 5 blocks for faster counting, and repeat numbers at the bottom/right -- but at the size the examples are in neither are needed)

(BTW you didn't mention for overlapping but there's a nice trick: just try from either end, count how many cells are leftover, and take that off the starting side of each block)