It's a waste, as I have only base purposes in writing Amazon reviews and linking to them from here anyway. I want a cool Amazon reviewer ranking under 5000. I want more hits on this blog, at least enough drown out my own clicks in the analytics. There's some vanity in the mix, yes. Like the guy who picks his teeth outside a fancy restaurant, I want you to see me flexing my per diem in the name of prestige and satiety! Now step back, you prole, for I have paid full price. I will now trumpet my findings to your sort as I see fit.

My store-bought imperiousness aside, I teach software, primarily to programmers and systems types. It's part of my job to evangelize said technologies through presentation, and show them off to best advantage. I believe my ultimate job, however indirectly the results manifest, is repeat sales -- helping users entrench for good reasons. I serve best when I can persuade users that the tools they have in front of them are ideal for their purposes: for work, personal technical growth, and for the inner nerd, enjoyment. Tools that are a pleasure to use and help to do work well are worth talking about.

Nothing impedes that goal more effectively, in my opinion, than presenting a piece of software as the sum of its parts, in exhaustive detail; ordering its presentation by rules, exceptions, and edge cases; and devoting as much or more attention to minutiae as to likely usage. It's not hard to see why this occurs frequently. Seeing software this way is an industry hazard for any developer's temperament. Anyone who has pored over source code, line by line, and documented mentally, if nowhere else, the limits of some software's capabilities, can be forgiven if their view of that product centers on the effort spent to produce it, the features created for well-meaning use, and the hard-earned experiences gathered on the path to completing it.

But why harsh on Exploring Expect, then, if its creator happened to run afoul of these traps? It's certainly not the only example available. I for one have picked on several other books for these same faults: Object Oriented PHP, LDAP Programming, Management, and Integration, and the PHP Pocket Reference, to name a few, although I am generally more charitable in those cases. I can manufacture a few reasons for being put off, political ones mostly. For example, I think the automatic veneration of O'Reilly animal books, all but canonized in the 90's, is overdue for a fresh look. lex & yacc immediately comes to mind: a title that has survived largely for being the only one of its kind, still gets bookseller shelf space, and yet remains written for the needs of an audience that, I would guess, no longer exists. Apparently people still buy it. Why? But that's a discussion for another time.

My big problem with Exploring Expect isn't a staying power that shouldn't be. And while I can't see why anyone insists on praising a book as if it stood for the technology itself or its creator perhaps, that's no skin off my nose either. The lack of alternative titles -- I presume no one feels they can trump what the brainparent has to say about his brainchild -- is mystifying. Surely people other than Bjarne Stroustrup or John Ousterhout may write C++ or Tcl books, yes? Ok then. So my problem is this: reading Exploring Expect, or trying to, made my job much harder than it had to be.

Sure, some of the fault lies with the reader. I wanted to make sure I understood this tool well, so I read the overview of Tcl, carefully. I've been around Unix a long time, but I felt obliged to read the sections on filename expansion (globbing), regular expressions, pattern matching, process management, and so on. I wanted to get the sense of this product, in part, through an agreement with the author on the underlying terms. When that didn't happen for me at first, I read again, trying to get a fix on the author. I still didn't get him, but I did figure out why. Exploring Expect isn't really trying to explain Expect to someone else; it's trying to explain Expect to itself, in a manner that seems to acknowledge the reader as a daunting, curious hurdle.

For starters, there's just no reason that Expect, a small and powerful tool, requires 500+ pages worth of exposition. Libes writes in the preface that the length owes to the "unique nature of automating interactive programs." After reading it, I just can't agree. Programs that interact with other programs solve the problem with protocols, simple specifications that dictate how an ineraction must be proceed in order to avoid confusion. What does Expect do that is so different? If there more to it than managing terminal-based output and achieving program efficiency, I haven't seen what that might be.

What I gather from the book's organization is that Expect, since it is built on Tcl, is a viable shell. Or an interpreter. Or an automation tool. Or a Tcl extension, a C library, or a framework for a debugger. Or, hey, all of them! And that Expect could be the first shell-like, intepreter-like, Tcl-like, scripting-like, or library-like Unix program the reader has encountered. Which, if that's the case, it would do well to rethink things from the foundation on up -- processes, signals, terminal behavior, you name it -- before opening the door to the house too much. Exploring Expect's view on what amount to standard Unix principles of operation looks for the evil in the details. Again, so far as I can tell, the search turns up nothing unusual. It's an idiomatic recitation as well, the kind that might lead a reader to wonder exactly which version of Unix the author uses. Seems a lot scarier than the one I use.

The book seems, in short, based with a step-wise compulsion over lots of concerns that don't seem unique to Expect at all. I found all that tedious, chafing and discouraging well before I got halfway through the book. Even at one hundred twenty pages in, barely a fourth, I could only remember that I'd used an FTP automation script once, and underlines a lot of rules and strange conditions, algebraic examples of those rules and strange conditions, and rewrites of script to avoid those rules and strange conditions...well. It took me a long, long time to get through this book, looking for a reason to pay closer attention.

What gets me most is that no one in 15 years has called out this particular emperor's fashion choices. Seriously? No one else has seen a need for a clear, practical guide on Expect? Jeepers, authors, there are more books on Microsoft Bob than there are on Expect. Can you help me out?