I am sorry but I just don't understand people's love of sloppy focus and corresponding hatred for click-to-focus. With sloppy focus you're even more dependent on your mouse...you have to keep it positioned over a window to keep it active. If you alt-tab to a new window you've gotta move your mouse over to it too. And if your mouse drifts off to the root window, all of a sudden you're losing keystrokes. What programmer wants to lose keystrokes? What programmer wants to constantly think about where his mouse is? This is idiocy. You supposed linux programmers foaming at the mouth about the greatness of sloppy focus are idiots.
Cygwin's integrated XWin window manager is sloppy focus & I can't figure out how to change the policy to click-to-focus. This is frustrating.
If I had my way this is how the typical data-centric (heavy on database & presentation layers, light on the logic layer) app would be written: in Perl; no classes or XML schema definitions, just straight sql tables (so no representations of the same thing to keep in sync); serialization between the db and Perl done automatically into nested hash structures, with foreign keys determining nesting structure; nested hashes serialized to and from xml via XML::Simple; presentation logic controlled by xslt & whatever glue is necessary.
I see far too many projects (my own KB, for instance, or our CSTS project last year in DS) mired in just the problem of converting data between various formats. Seems like with these projects 90% of the code is devoted to that and only 10% to *actually doing something*. So we need to make this conversion as inexpensive and automatic as possible.
After one day with VC# 2003 Enterprise Architect Edition, I already have following list of irritations:
Yeah I think Connect-4 is gonna be more than I bargained for, ie rather than using a brute-force lookahead it would need a lot of rule-based play and positional analysis. Check out the following link on expert play in Connect-4.
Here's a crummy problem I ran across the other day. I had this line in a Makefile:
g++ -L../../lib -lgamework -o Connect4 $(objects)
The compiler wouldn't pickup any of the symbols from the libgamework.a library, as if it wasn't even being linked in. I assumed this was some weird problem related to namespaces and static linking. However, it turned out the order of link args is important, because this worked:
g++ -L../../lib -o Connect4 $(objects) -lgamework
The symbols referenced by $(objects) are resolved when they're found in libgamework.a. If libgamework.a is the first arg, none of it ends up in the executable because no symbols need to be resolved at that point.
Well I got around to implementing Connect-4 under GameWork. Took me all of 2 hrs, but the AI stinks. The problem is not a big branching factor. As noted before the branching factor is at most 8, and this even tends to decrease as columns fill up. The problem (I think) is that the game isn't won slowly, by degrees, but all of a sudden. Unless I can find a way of objectively valuing the intermediate game states the lookahead will continue to stink.