Dear DDJ,
I'm appealing to your readers for help in finding a copy of the book A Small C Compiler by James E. Hendrix. The publisher put it out of print. If anyone has a copy they're willing to sell, please contact me.
Martin Schaaf
P.O. Box 761
Alameda, CA 94501
DDJ responds: Martin, in response to requests like yours, we're about ready to release Dr. Dobb's Small C Compiler Resource CD-ROM that will include the full text to Jim's book A Small C Compiler: Language, Usage, Theory, and Design, collected DDJ articles on Small C, several implementations of the compiler, and related Small C tools.
Dear DDJ,
I enjoyed reading Jonathan Erickson's November 1996 editorial and wholeheartedly agree with his assessment of how difficult it can be for software publishers to get placement in the retail channel. Our company, Online Interactive, offers an alternative solution for software publishers trying to distribute their products. Online Interactive operates a series of electronic download stores called the "atOnce Software" stores (http://www.atonce.com). Our first store opened on the Internet in January, 1996 and was one of the original participants in Microsoft's electronic software-distribution pilot program. Since then, we have opened additional stores on America Online, CompuServe, and the Microsoft Network. We have licensed over 125 software publishers, including GT Interactive, Intuit, and Asymetrix; more importantly, we represent a host of smaller publishers that are successfully using the download channel to generate revenue and reach customers. With over 1500 titles available for instant delivery, we will soon surpass the selection of even the largest computer superstores.
Robert Nachbar
RobertN@online-interactive.com
Dear DDJ,
Alan Cooper's September 1996 article "Goal-Directed Software Design" presents laudable principles. However, I'm always concerned when realistic examples don't derive from principles.
What really caught my eye was the caption for Figure 4: "The monthly view in Schedule+ is a paragon of pixels sacrificed on the altar of meaningless regularity." (The figure itself shows a traditional paper-style monthly calendar layout displayed on a computer screen with lots of wasted space.)
My technophile instinct wanted to jump up and applaud Cooper for advocating a move away from now-irrelevant limitations like the static nature of information presented on sheets of dead trees. And I certainly wouldn't choose to defend a Microsoft product under ordinary circumstances. Unfortunately, a few seconds later I realized there was a problem.
For in-house corporate developers, it might be possible to provide a more dynamic display or at least one which wastes less screen real estate. In this situation, users are haunted by the twin specters of necessity and inflexibility: The software is more likely to be mission-critical and less likely to be provided by more than one vendor. Users here are more likely to be willing to slog through the (admittedly small) paradigm shift because they've been shifting this way for years to accommodate alien software.
But for independent software vendors who must induce skeptical and often deeply conservative customers to part with hard-won cash, imposing a new calendar display paradigm is no way to win mind-share. These users are more likely to greet unfamiliar displays of familiar data with knee-jerk rejection or MEGO ("my eyes glaze over"). According to Cooper, this might be the user's fault; Cooper might say the user has a "false goal." But educating users is not usually the job of a software interface designer.
Of course, it's possible to satisfy all users by providing both a traditional and a more efficient calendar display. However, it's not always practical to develop both.
The principles of goal-directed user interface design sound good, but I'm still waiting for a "killer" case history.
Pete Gontier
Pleasanton, California
Gurgle@aol.com
Dear DDJ,
I read Alan Cooper's article "Goal-Directed Software Design" (DDJ, September 1996) with interest, having previously read his book About Face. Generally speaking, what he writes expresses clearly what I feel, although we occasionally disagree.
The disagreement at hand concerns the phrases on page 18 (DDJ) "...an embarrassment of compute-cycle riches." My biggest complaints about the software I use are generally: 1. bugs, and 2. slowness. The article didn't talk a lot about the Bane of Software -- bugs -- but maybe they're more of an implementation than design issue (maybe not always, though). But on slowness, he doesn't even seem to think it exists!
It has been my experience that no matter how fast the hardware, I end up waiting, wondering what on earth the programmers have cooked up to waste the time. I guess we agree to the extent that nowadays I tend to blame the software more than the hardware.
Stuart Ambler
Longmond, Colorado
Dear DDJ,
I would like to take this opportunity to respond to some criticisms of Java that were made by Luca Passani in his letter in the September 1996 DDJ. There are a number of criticisms of Java that Luca makes, that are inaccurate and misleading.
Luca's statement that Java applets can't and never will be able to write to the local filesystem is incorrect. The current restriction on access to the local filesystem is not a restriction imposed by Java, but is rather a restriction imposed by Netscape's Navigator. Web browsers can create security managers which allow for any degree of granularity of access to local system resources -- Sun's HotJava browser, for example, allows applets to write to directories on a user-specified access list; future browsers could implement more complex security managers. For example, a security manager could be written that allows applets that are loaded from specific hosts, carry a specific public key signature, and so forth, access to specified directories in the filesystem. Luca's contention that the only alternative to "no access to the local filesystem" is "full access to the local filesystem" is incorrect.
Luca also contends that no "serious applications" have been written in Java, and that Java is too slow to download and run. His first claim is patently false; I point to Sun's HotJava browser and Java WorkShop development suite as examples of "serious applications" written in Java. The fact that there are many "eye candy" Java applets out there is a function of the fact that, until corporations start adopting Java, hobbyists (such as myself) will continue to be the primary users of Java. However, that trend is changing rapidly, and I see this balance shifting rapidly over the next year or two.
Luca also compares the relative complexity of Java (requiring "professional developers for not so complex applications") with the simplicity of HTML. This is a flawed comparison, as HTML is not a programming language. A much better comparison would be to compare Java with C++ or Perl, both of which require developers with some degree of skill for even fairly simple programs. Users who are simply building web pages can download and use any number of prewritten Java applets (the Gamelan repository is one such source of applets). Custom solutions have always and likely will always require professional developers.
Also, Luca makes the statement that it is better to use other RAD tools and TCP/IP client/server approaches than to "waste time and money trying to make your requirements fit the Java paradigm." I utterly fail to see how the "Java paradigm," as he puts it, is any different from any other OOP programming paradigm. In fact, it is my experience that developing complex TCP/IP client/server applications in Java is significantly easier than developing them in C or C++. The language is somewhat different, but there is no clear advantage to other RAD solutions, except in the area of GUI builders. And the drag-and-drop GUI builder (such as Delphi's, for example) is already available for Java from at least one vendor. (Rogue Wave's JFactory.) I do not see a disadvantage to using Java here, and in fact, Java has several advantages in terms of security and network programming.
I will concede that there are some bugs in the current implementation of the AWT toolkit. However, as time goes by (Java is, after all, barely a year old), and these issues are resolved, Java will become that much stronger. Luca's criticism of the speed penalties for downloading and running Java applets can and will be resolved as both Internet bandwidth increase and mechanisms are developed for caching applets. Luca's criticism of "...having to download a Java .PDF-life reader every time you encounter a .PDF document" only remains valid if you assume that you have to download the applet every time. If a mechanism could be created whereby the applet could be downloaded and stored persistently on your local hard drive (and such a mechanism is not difficult; Netscape's Navigator already does some caching of applet data), this would turn into an advantage rather than a disadvantage. (I'd rather download 200K of compiled Java code than a 4-MB ZIP file, which I had to install on my system, for example.)
In summary, I feel that Luca's criticisms of Java are based on an incomplete understanding of exactly where the limitations in the current implementations of Java-based technologies lie, and that his comments are extremely misleading. The majority of the limitations currently encountered in Java applets are limitations not of the applet, nor of Java, but of either the web browser or the hardware network connection. Java certainly does have some limitations, which will be solved as more people adopt Java and more effort goes into resolving those limitations, but the arguments that Luca makes against Java are incorrect and misleading.
Matthew Cravit
Palo Alto, California
mcravit@best.com
DDJ