Several more highly recommended books in the scientific games genre, like Moneyball which I reviewed earlier.

Poker Nation and Positively Fifth Street are both books about poker, specifically centering around what has become the standard game among serious players, no limit texas hold 'em. I recommend you first read Poker Nation. It's a quick read, gives a good overview of the culture around the game and the psychology of playing it, and covers basic strategy. Positively Fifth street is much longer and has a much stronger narrative structure. It covers in parallel the murder of Ted Binion, owner of the Horseshoe casino in Las Vegas, and the World Series Of Poker, held in that same casino. The author decided to spend his budget for writing an article on entering satellite tournaments. You should avoid reading the back of this book before you're done with it, it gives away a lot of the story.

Word Freak is a book in the same genre but about scrabble. It's very comprehensive, covering the culture around the game, the trademark issues around the name, the controversy over dictionaries, tournaments, computer play, history of the game, basic strategy, and just about anything else you might think to wonder about it.

The unusual thing in common among all these books, and why I love them so much, is that they cover the issues of luck and chance unflinchingly, pointing out just how much of chance there is among who wins the big tournaments and how little meaning the patterns we read into winning history really have.

That exhausts all the books I know of this genre. I'd be happy to hear recommendations of others.

GUI Library APIs

GUI libraries, it seems, are designed poorly by tradition. Sure you could design one which isn't a big steaming pile of manure, but why break with tradition?

In case anyone reading this might happen to write a GUI library and want to break with tradition, I will now give a very high-level overview of the Right Way to do threading in a GUI library.

There is a separate thread which does nothing but graphical display. This isolates all the potentially CPU-intensive grahical tasks from the main application, and also prevents the application from making the GUI thread block. In addition, it enables lots of performance enhancements like having the GUI thread notice that a window was closed halfway through doing some CPU-intensive graphical effect on that window and not bothering to finish.

The only time the application developer writes code which will be executed in the GUI thread is when they're writing their own layout or widget code. All the calls to make things happen in the GUI (such as changing text or resizing windows) are threadsafe. This puts an end to all that clumsy invokeLater() crap which all the GUI library authors seem to think we love doing.

When events happen in the GUI they come back as callbacks on a special-purpose callback thread. If there are multiple processes then there's a separate callback thread per process, so that they can't lock each others's interfaces (note that Java got this horrifyingly wrong). If you as the GUI library author are feeling ambitious you can make callbacks be events pulled off a queue in a way which can be integrated into the application's main event loop. Of course, doing that without polling requires making a decent event notification system, but that's a whole other rant.

There are a few small details which should go without mentioning but in practice don't so I'll cover them now.

Good double buffering should be supported in 1.0. Actually, it should be supported in the first alpha version.

It should be easy, nay trivial, to make windows which resize nicely. Graphical widget layout tools are a symptom of execrable libraries.

It should be possible to make a modal window display without blocking. In particular, anyone who writes code which automatically fires off a new thread while the previous one is blocking needs a good beating with a big stick.

Yes I've been haggling with GUI stuff today. How could you tell?

P vs. NP

Scott Aaronson has an interesting paper on whether P vs. NP is formally decidable. He makes an interesting distinction between P vs. NP and the continuum hypothesis. We can imagine a very specific physical process which corresponds exactly to the truth of P vs. NP, but no equivalent exists for the continuum hypothesis, thus P vs. NP is something which we philosophically view as strictly true or false, regardless of whether we can ever prove it, while the continuum hypothesis might have a much vaguer independant state.

I'd like to point out that we can almost make a physical process which corresponds to the continuum hypothesis. Specifically, we can make a machine which assumes the continuum hypothesis and systematically proves all possible statements and halts if it ever finds a contradiction. However, this physical process doesn't correspond to the continuum hypothesis per se, but to whether the continuum hypothesis is consistent with our axiomatic basis, which is a subtly but importantly different question.