| Programming Challenges / Steven S. Skiena and Miguel A. Revilla | ||||
| Reviewed by Tal Cohen | Sunday, 03 December 2006 | |||
I personally dislike the very notion of programming contests; and yet I like this book and very much enjoyed it. The problem with contests, in my view, is that they put too much focus on the very wrong thing, namely, fast coding. It is true that a programmer cannot win the competition if his program is wrong, but he can’t win it if he’s slow, either. And from my real-life experience, slowness can be a very important trait in a good programmer. Not slowness in the sense that makes him boring or dim-witted; rather, slowness in the sense of not rushing anywhere before beginning his work. Google for the term “good programmers are lazy” to see what I mean. In other words, the competition setting encourages the contesters to rush ahead and code the first solution that comes to mind. While the first solution — with good programmers — is often right, it is rarely also the best solution. I personally find that after sleeping over the problem, or musing about it in the background while reading a good book about something totally unrelated, I am able to come up with a much better take on it. But clearly this is not possible when there’s a stopwatch ticking in a referee’s hand. Still, even if I don’t like programming challenges, I like Programming Challenges. After all, there is no time limit whatsoever when facing it at your own leisure. The book contains very good puzzles, from a simple Minesweeper-mapper to complex combinatorial and geometrical mind-benders, the book presents a lot of fun for the devoted reader. And every chapter is preceded by a good theoretical discussion of the issue at hand. I believe it really can, as the cover promises, make you a better programmer, and if you enjoy this kind of stuff, it literally delivers hours of fun. Some criticism, though. The automatic checking, performed by submitting your solutions (as source code) to an online “judge” website, is a vital part of the process. Sadly, however, this also limits the programming languages you can choose as your weapons when attacking the dragons lurking between the book’s covers. And the choice is limited indeed: C and C++ (which I personally think are totally inappropriate — from a software-engineering point of view — for many, if not all, of the tasks presented), Java, and (surprisingly enough) Pascal. I find that many of the problems are better solved with higher-level languages, such as scripting languages (Python comes to mind) or, e.g., Lisp. Clearly, when development time is of no less importance than program performance, the choices given are mostly inappropriate. And since I make a living using Java (or rather, telling other people how to do that), I naturally chose this language for writing my own solutions; but apparently the judges’ support for Java is limited, if not downright broken. Looking at the surprisingly low success rate for submitted Java programs (about half the success rate of C programs), I suspect that I am not alone in facing this problem. Finally, another thing that bothers me is the too-great focus on having the reader work hard to properly understand the problem; as if the requirements specification is a legal document, but with no counselor that you can contact if anything is not really clear. Sure, understanding requirement documents is an important part of real-life software development, but doing so by facing terse textual descriptions, which are often spares on details and examples very purposefully, is rarely realistic. Don’t buy this book before checking out some of the examples for problems presented in the archives of the competitions (linked above). If you do like them, the book is a real treasure. So: do you think you’re up to the challenge? Give it a try. Just remember not to give up if you fail a challenge or two; move ahead to the next one, and (like any good, lazy programmer) let the previous challenge bother you at the back of your mind until you have that wonderful feeling of “Aha!”.
| ||||
©1997-2022 by Tal Cohen, all rights reserved. [About]
