A Review by Dwight Scott Miller
Coming from a background of thirty-five years of programming, encompassing more than two dozen languages, I approached the review of this book with considerable enthusiasm, hoping to add yet another syntax to my repertoire. Said background also including several years of teaching, I also approached with considerable concern for the method and content, having been disappointed recently with a large percentage of the publishing in computer techniques. I insist on technical depth and accuracy couched in excellent grammar and have little tolerance for patronizing or condescension. In this volume, Schindler & Schindler have not let me down and, although I have a nit or two to pick, I heartily recommend the book to both the novice and the guru. The novice will get both a good grounding in the REXX language and a selection of excellently written code; the guru will be exposed to a spectrum, the value of which will depend on his experience and his style, but which will encourage him to contemplation of his practice in any case.
I completed Day 1 through Day 6 in one calendar day, covering ``getting Started,'' basic rules, variables instructions, and elementary I/O. The tip on launching the Enhanced Editor is worth wading through the first lesson, even for the experienced programmer, unless the EPM is already second nature to the reader. The text is very gentle, although a few attempts at humour do not come off very well. I like the comments on programming style for the beginner. The Q&A section is excellent, bringing out quirks that experienced programmers might skip and that they should know.
On my second day I got to the end of Day 11, learning about program control, e.g. loops and conditionals1, string manipulation, and some debugging strategies. The authors lean heavily on the ``Principle of Least Astonishment'' but they also lose sight of it at times and use a function without comment. They also imply an adherence to conformity as a philosophy that I do not espouse. It is a great liberal idea, but uniqueness, when combined with usability, may be a better sales tool. Although interfaces require standards and style must be conveniently transportable, context, i.e. the use of code, is important. Development must take in to account the talents and shortcomings of the intended audience.
After a lot of detail, the example program for the wrap up of the first seven days is rather lame and does not use any of the material presented on days one, three, or five. (I will admit that Day 1 is entirely introductory and contains no code.)
The Week 2 Intro says, ``By the end of week 2 you should ... accomplish nearly any task.'' Then why do we need Week 3? It turns out that the third week is the entire I/O system and all the externals needed to handle the WPS, hardly a trivial section! I suppose also that many more folks than I run into on a daily basis need to calculate Greatest Common Denominators, but I can count on the fingers of one hand the times I have had to do it in two decades. The method selected for the example on Day 8 may be elegant code, but what is the purpose in selecting pretty rather than relevant? One must also wince a bit at the ``Q&A'' lines: ``Is it better to (this) or (that)?'' followed by ``Neither is best in all situations.'' Let us be either comparative or superlative as we please, but let us keep the count of the compared elements in synch!
No output is presented for the three examples of the translate function. Providing the result of each example would be a nice gesture. I object also to the claim that it is unnecessary for a programmer to know base notation and arithmetic.
I thought I had found a couple of technical errors in the text, places where the given result did not match the proposed code. Bill Schindler discussed one of the listings with me and we resolved my concerns (turns out I was reading a line right to left whereas Bill read it left to right), but the second listing (10.3) contains a mistake. Considering that the book is over 500 pages of what looks like 10-point type, this is an extraordinarily low occurrence of errors. Day 10 also contains a very cute debugging trick. Having a program start the text editor with the program source loaded and the cursor at the errored line is about as slick as it gets.
My third day chalked off only three chapters, Day 12, 13 and 14, but they included a lot of material. Day 13 contains a good introduction to handling user input, although the topic could easily do with a complete book of its own. I'd go one step further than the authors and say that, even worse than inadvertent deletion of a file, which should come to light fairly quickly in the course of events, is the covert corruption of a file, which may not become evident until far too late to avoid serious consequences or to apply corrections. Compound variables and subroutines are the other items in this section.
Although the analysis in the Week 2 summary is short, it is sufficient and the checkers playing program is actually playable and rather amusing. One technique that Bill and Esther are using is to reduce the hand-holding of the reader as the lessons progress. The reduction is proceeding at a precipitous rate, even if it is as smooth as a well-built roller coaster. The authors will have to stretch some if Week 3 is not to become a deep reference manual.
I started into Week 3 on a Saturday, so I had enough time to complete the book, including the appendices before going back to work on Monday. After a brief warning that we intend to become SOM experts in seven days and we plunge into Streams (general I/O), utility functions, the Workplace Shell, and interprocess communications.
Embedded in this discussion, I come across answers to several questions that I had while looking at VX-REXX. While the explanations the Schindlers give sometimes leave out, or do not make explicit, a particular parameter, their examples usually do. The examples are very practical and are exactly the type of things that I write myself, often as 4OS2 aliases, thus highly valuable to me. Considering the freedom of style offered (tolerated, maybe?) by REXX, I find the habit of using a new function without in-line comment to be annoying. Although the explanation is given in the Analysis section following the program, those of us who try to analyze on our own before reading past the code spend time with head scratching and appendix digging that would not be needed if a note were included in the text. After spending much of ``Week 1'' exhorting the reader to comment his code, the authors proceed through the rest of the book in a fashion that leaves the reader as much at a loss for purpose as a lumberjack in the Gobi desert. Although this part of the book is more reference-like than explanatory, the examples of navigating the OS/2 structure, particularly the desktop are a veritable gold mine for anyone who has not already studied OS/2 internals.
The section on .INI files, however, is too light. It will likely lead the tyro into destroying his OS2.INI or OS2SYS.INI with its oblique, flip, and trivialized warning about the consequences of meddling with these files. If the authors did not want to go into much more depth than they did, they should have left this section out. On Day 20, the Schindlers deliver a nice slam on IBM's help screens in the EPM, but then go on to a top notch treatment of enhancing the enhanced. If the reader has not been through the archives on Compuserve or engaged in deep discourse with Dave Whittle, the capabilities of the EPM revealed here may well cause some dropped jaws.
As I go through each chapter, even with the occasional gripe, I keep feeling that, in terms of practicality, this book far outshines the ``Unleashed'' volumes, even though the most intriguing parts relate to REXX as a platform much more than as a language. As I reach Day 21, it is nice to see the ``Do's & Don'ts,'' which seemed to have disappeared about Day 13, back again. The description of Pipes and Queues is short, but sufficient; the topic is not, from a concept point of view, particularly complex. Semaphores should probably have been left out or mentioned only in passing, since the semaphore file, while common, is a lousy technique. System provided semaphores, such as those in Novell Netware or the mainframe MVS lock system are much more robust but could not be covered in this book since they are not available to REXX without third party libraries.
The culminating example is an expanded DIR command, in Bill Schindler's very readable and efficient style, that is well worth typing the 485 lines needed to have it running on the reader's OS/2 system. It really does include a bit of everything in the course.
To put paid to it, the book is a ``must have'' for beginners and casual REXX programmers and a delightful look into some nooks and crannies for the experienced. The style is smooth, the examples usable, and the content deep enough. I'd buy it -- in fact, I did.
Return to Reviews index
Return to TAMU OS/2 Users Group home page