I used to use Perl a lot in the old days. Martin Albrecht, through the sage mathematics software, showed me Python. I first really hated Python. But then, I realised I can simply type away in it, as in C++, but without all the hassle of C++. I saw a little of AWK once, and I got madly in love with it — when it comes to simple scripts like counting numbers printed by programs, AWK is unbeatable. I use grep a lot, and recently I realised how great a combination grep and wc (a very dumb utility that counts lines/words) are. For instance, I can simply do: “grep “s SAT” *.output | wc -l” to find how many problems have been solved by CryptoMiniSat. I am also finding myself using grep and AWK together to create shell scripts that I run later. For example, I can do: “ls *.cnf | awk ‘{print “./cryptominisat ” $1 ” > ” $1.output” }’ > script.sh” which, when executed, solves all CNF files in the directory, and generates a *.cnf.output file for each, containing the output of CryptoMiniSat. An interesting utility in UNIX is ulimit, with which can limit the memory and time (and stack, etc.) usage of a process. Putting a “ulimit -t 10000” at the beginning of our “script.sh” we can simply limit CryptoMiniSat to 10000 seconds for each instance.
As for failures in terms of the tools I use, I can probably list a few. I tried very hard to learn Haskell, a purely functional language, but I simply couldn’t fully wrap my head around it. Haskell bothered me, because it seems so intuitive, yet it is so hard to master. I haven’t yet got around learning sage, either, even though I think Martin Albrecht is doing a great service to the community by coordinating it. I hope one day CryptoMiniSat will be used inside it, though :)
My connection with the boost library is a love-hate relationship. I think boost is just amazing: it lets me program with the least amount of effort, creating a program that is less error-prone, more robust and multi-platform. However, at the same time, many programmers avoid it like the plague, for multiple reasons. Firstly, the library changes so often that something you wrote just two months ago might not compile with the new boost. Secondly, it’s a nuisance to have dependencies in the code. Thirdly, compilation times can increase significantly e.g. with the Spirit parser. I don’t agree with the second argument, since boost as a dependency isn’t significant and it saves on a lot of debugging time, and the third argument is becoming moot due to gcc 4.5. But the first argument has, actually, hit me too, and it is very unpleasant.