ToDADS: Annoying Amazon review

published: Wed, 18-Jun-2003   |   updated: Sat, 20-Aug-2016

As I'm sure you are aware, the various Amazon web sites enable customers to post reviews of books they've (presumably) bought. We authors cannot respond very easily to these comments (I think there were some problems in the past with this facility), which is certainly annoying when faced with reviews containing mistakes or misunderstandings.

However, by using this web site, I can respond to criticisms and right wrongs. I promise to be fair though—some criticisms are certainly deserved and I shall address these by adding extra articles to this web site that clarify issues or correct errors.

Roy Hurley's review from 9-Jan-2002

First, here's the review as written on Amazon.com... (Sorry, I couldn't resist: like a prim old-fashioned English school teacher, I've marked out spelling errors.)

The book covers arrays,lists, stacks and Queues [sic], sorting, random number generation and testing, hasing [sic] and hash tables, binary trees, state machines and expressions and data compression.

It's [sic] decent coverage of the topics, well explained concepts and is supported where required, by diagrams and source code.

One of the things I didn't like about the book is that it contains too many long printouts of source code, rather than devoting space and effort on explanations and concepts. The CD should contain endless reams of source code, not the book!

what this means is that the book is twice as large as Rod Stephans [sic] excellent "Ready to run algorithms" Series, and only contains about 70% of it's [sic] goodness. Rod did a much better job of compressing the big picture explanation into print, and more econmomical [sic] use of example code.

Also, the author relies on, and uses pointers far too much within his code, rather than using Delphi's other ways and means. I think this detracts from the elegance and simplicity of many implementations of the algorithms.

Having said that, if you you already own Rod Stephans [sic] bible on algorithms, this is a reasonable back up purchase, if you have spare cash.

My turn now. The first criticism here is "too many long printouts of source code." Ahh, a difficult balance to get right. I agree with Hurley's implicit general criticism here: there are too many books out there that slam major chunks of code into the text, code that can go on for pages and pages. I tried very hard to break up the code within the text, so that the description could refer to the immediate listing, rather than the code a couple of pages back. By no means is all the code present either: you'd have a fairly hard time compiling it after typing it in; you need the CD. Nevertheless, I'll take the criticism on board and try to do better next time.

The second criticism here is "the book is twice as large as Rod Stephens' [book]." I'm sorry, but this is just plain false. Stephens' book is 416 pages, and mine is 526. About 25% larger, not 100%. I'll agree that it seems that much larger (Wordware have printed mine on fairly heavy stock, compared with Wiley's treatment of Stephens' book), but the implication here is that I've deliberately padded my book with source code to make it look larger. Not so.

The third point that I disagree with is "Rod Stephens' excellent 'Ready-to-Run Algorithms' series." Red rag to a bull, this one. Long before I started writing my book, I wrote a long review of Stephens' book (at least in its Delphi incarnation). I won't rehash it here. Note also that Stephens has two (count 'em) errata on his web site for his book. (Update: on 18-Jun-2003 there were still two, and I just noticed that the main page for the book states categorically that this book is "The only guide to algorithms in Delphi". Uh huh.) There are a lot more issues that are not mentioned. I, on the other hand, am trying to maintain a full up-to-date list of errata.

The fourth criticism here is my book "only contains about 70% of its goodness." ("its" referring to Stephens' book.) Major red rag, this time; in fact, almost a sheet. I will agree that Stephens' book talks about algorithms that I don't: recursion, quadtrees, AVL trees, decision trees, network algorithms, some smaller algorithms. I'd forcefully point out that my book deals with some algorithms that Stephens' doesn't: red-black trees, random number generation, state machines, regex string matching, extendible hashing, data compression, Readers/Writers, Producers/Consumers, longest common subsequence. (It's also interesting—and contradictory—that Hurley mentions several topics in his initial list that the Stephens book does not cover.) In other words, it's a Venn diagram with two sets having a common subset of items between them, not one set completely enclosing the other as implied by Hurley's comment.

Also, "goodness"? Let's see: Stephens talks about "object-oriented paradigms" without calling them what they really are: design patterns. He presents an "optimized" quicksort that's slower than the unoptimized one that we get in TList. Having had a chapter on recursion, talking about its good and bad points, he doesn't remove it from any subsequent code nor does he discuss the benefits/drawbacks if you did. The code is not Ready-to-Run (for a start some of the code printed in the book is badly converted from Visual Basic). He discusses hash tables but doesn't discuss hashing algorithms. And so on.

The next point: "Rod did a much better job of compressing the big picture explanation into print." An arguable point. I'll agree that Stephens does have a way with words and explains things well. I also get praise like that <g>. But, much better? I'll drop this as being too subjective.

I'll finish with "the author relies on, and uses pointers far too much within his code, rather than using Delphi's other ways and means." Ah, well, touché. I've had this criticism before; another one, from Tom Lisjac's review, is that I tend to write console test apps. These problems stem from being an old-school Turbo Pascal programmer, I'm afraid. In my defense, I'll say that I am trying to get better (I've made a conscious effort to use classes more in my monthly Algorithms Alfresco articles and the test apps are slowly using more GUI). Another point to make about this criticism is that I wrote the code to be compilable with Delphi 1. I wonder if Hurley is really complaining about the multiplicity of dereference carets in the code, which Delphi 1 requires but that the others don't?

I'd have to say though that Stephens' code suffers from the same problems: pointers galore, not too much of the "other Delphi ways and means". But, hey, it's the 'bible'.

(Interesting side note: I originally wrote this rebuttal in my lunch hour. I wanted to check something in Stephens' book, so I went round all the programmers' bookshelves here at TurboPower looking for it. Not a copy to be found.)