Dear DDJ,
Further to our article, "Spatial Data and the Voronoi Tessellation" (DDJ, December 1992), we would like to report a significant new development to those developing geographic applications.
The U.S. Defense Mapping Agency, in cooperation with their counterpart agencies in Canada, the U.K., and Australia, have recently released the Digital Chart of the World (DCW). This "chart" consists of over 1.5 gigabytes of reasonable-quality vector data distributed on four CD-ROMs. The set provides worldwide coverage of 17 themes, including coast-lines, rivers, roads, railways, airports, cities, towns, spot elevations, and depths, and over 100,000 place names. Much of the vector data has been digitized from the 1:1,000,000 scale Operational Navigation Charts (ONCs) used by flyers the world over. The price tag? $200.00!
For the first time, developers everywhere can affordably include general geographic objects in their applications. Because the data is in vector format, with varying amounts of work, proper spatial objects can be constructed. Then spatial relationships between them and other application-specific objects can be calculated. But even if an application might not need this data to construct spatial objects, all can use data like this for graphic user-orientation purposes.
The PC-access software provided (VPFVIEW) permits you to browse the world, selecting location, scale, and theme. Selected features can be extracted and used in your own application, without copyright violation. The access software is written in C and source is provided. To be sure, the access software is painfully slow and at times unstable. But no matter, that can be remedied easily enough. The main thing is that general geographic vector data is now available at a truly remarkable price! Besides the CD-ROMs (ISO-9660 compatible) and the 80286/287 diskettes, you get installation instructions and a user's manual. Sources are provided for technical information describing the external data structures.
Here are four sources of the DCW:
U.S. Geological Survey P.O. Box 25286 Denver Federal Center Denver, CO 80225 Digital Distribution Services Energy, Mines, and Resources Canada 615 Booth Street Ottawa, ON K1A OE9 Canada Director General of Military Survey (Survey 3) Elmwood Avenue Feltham, Middlesex TW13 7AH United Kingdom Director of Survey, Australian Army Department of Defense Campbell Park Offices (CP2-4-24) Campbell ACT 2601 Australia
Hats off to all four governments for this latest "open skies" initiative.
John Russell
Calgary, Alberta
Canada
Dear DDJ,
Let me first say that I really enjoy your magazine. Keep up the outstanding work on your indispensable publication--it is the best of its type anywhere! However, I was disappointed that your annual issue on object-oriented programming did not address the current enhancements being made to Ada 9X. Perhaps you can address this next year when the revision is finalized.
Speaking of languages, I'd like to say a few words about the uncharacteristically biased presentation in your October 1992 issue, "Safe Programming with Modula-3" by Sam Harbison. In his zeal to promote his favorite language, Mr. Harbison doesn't look before he leaps. Specifically, he says, "Even Ada ... does not protect you against dangling pointers...." On the contrary, Ada specifically addresses dangling pointers and does provide some measure of protection. Pointers in Ada (access types) are automatically set to null when instantiated, and reset to null when the user exits the block they are declared in. (Of course, it's still possible to dangle pointers within the declared block, but that's why we train programmers, right?) Furthermore, to suggest that Modula-3 is more "safe" than Ada is ludicrous! Any runtime type checking is, by definition, less safe than the static type checking required by Ada.
Sam declares that there are many features "already found" in Modula-3, and then insinuates that current standard revisions in Ada and C++ are playing catch-up. This is a rather immature stance to take. Since Modula-3 is a new language, one would expect it to incorporate modern concepts. Just because it is now being "released" while Ada and C++ are being revised, this timing doesn't make it a better language! All useful languages are defined by standards which, at any point in time, are always in a state of flux. To assign some sort of qualitative value on this unrelated temporal relationship is meaningless, especially if the subject features are in the process of being implemented anyway (which the author points out). If the author's opinion was that these features are currently supported in Modula-3 and not in the other languages, this point could have been adequately expressed sans the subtle religious overtones.
As the article failed to point out, there are several features of both Ada and C++ that are not found in Modula-3. In addition, several of the language features of Modula-3 and C++ were borrowed from Ada (exceptions, generics, separate compilation, etc.). In my opinion, the option to use multiple inheritance in C++ is one of its greatest assets because a design may be implemented directly by the language. And Ada's support of concurrent programming, low-level programming, built-in attributes, and support of programming in the large are unmatched by any popular language. Furthermore, both Ada and C++ do not specify automatic garbage collection for a reason--not only are there many different ways to implement a free-list scheme, but also language-imposed garbage collection is always machine-dependent, restricts flexibility, and exacts a runtime cost. Lastly, the automatic initialization of variables can be just as dangerous as no initialization (which a compiler can catch), by potentially rendering a false sense of accuracy.
Aside from the biased presentation, I found Modula-3 interesting. Like any language, it has its place depending on the application. However, if the author's motive was to truly compare the relative utility of a language, a more useful question to ask would be, "Is there anything I cannot do when using this language?" I can answer this question positively for every language I have ever been exposed to and certainly for Modula-3.
In closing, let me say that I advocate the diversity of expression allowed by the existence of many programming languages. I have never understood the need of some to extoll the virtues of their pet language at the expense of other languages (except, of course, to use the other language to better explain the features of the subject language in an objective fashion). All languages have varying levels of support for different features. I prefer (and expect) to read an article that takes a positive approach to introducing these features over one which seeks to establish some sort of childish ranking scheme. Judging from the usual high caliber of the letters printed, the readers of Dr. Dobb's are a little more sophisticated than this article seems to presume. In the future, just the (correct) facts, ma'am.
Spencer Roberts
Redondo Beach, California
Dear DDJ,
I was surprised to see another letter about the MOD function in the September 1992 issue. Perhaps your readers would be interested in how Ada deals with the matter. Ada has two functions, rem and mod. rem is the integer-division remainder operator, and returns the same result as the Pascal mod operator; the result always has the sign of the left operand. mod implements the mathematical modulus operation, and the result always has the sign of the right operand.
I was also surprised to see another letter about implementing a generic swap in C. I should say that I view C as a fairly successful attempt to create a more-or-less portable assembler, and as such should be considered a low-level language, or at best a mid-level language. I would reject any claim that C is a high-level language. Perhaps the many C users among your readers would enjoy seeing how this operation can be implemented in a high-level language, again using Ada, as in Example 1.
generic
type t is private;
procedure swap (left : in out t; right : in out t);
procedure swap (left : in out t; right : in out t) is
temp : t := left;
begin -- swap
left := right;
right := temp;
end swap;
This will work for any type for which assignment is defined (in the interests of safety, Ada allows the definition of types for which assignment is not defined, and it is immediately clear what the code is doing, unlike versions which make use of multiple exclusive ORs.
Jeffrey R. Carter
Sterling, Virginia
Dear DDJ,
I take exception with Al Stevens's April 1992 "C Programming" column, in which he states that programmers will not become obsolete. I agree, but not for the same reasons. There will always be a need for those who dedicate themselves to a field of expertise.
Al states that, "...a decade later, we are no closer to user-written programs." Apparently he lives in a closed C environment. My own experience with Borland's ObjectVision would discount this. There are other examples out there.
Al uses C++ as his standard programming environment to support his argument that programmers are still needed. What C++ needs is not programmers but C++ construction experts. Most of the C++ programming effort is not spent writing a computer program but building the foundation for that program. There are more efficient methods to create computer programs. More efficient for the programmer and for the client spending large amounts of money to hopefully get what he is paying for.
Al states that, "...to be a complete programmer you still need to know how to design, code, test, and install a program, and for that you need skill, discipline, and structure, and all that is getting harder, not easier." Does this mean a doctor or accountant does not require skill, discipline, and structure? I have known many professionals who have been forced to learn a computer language, never C, in order to get the required computer program. Computer programmers may know how to write a program, but damn few know how to listen to the customer. One thing these professionals do is first select a computer language that best fits their needs and requirements. Most have selected Pascal. None have used C.
Because these nonprogrammer professionals took the time to select programming platforms that efficiently get the job done, patients and clients still have doctors and accountants who haven't been bankrupted by C++ overkill.
John S. Krill
Santa Ana, California
Dear DDJ,
Thanks to Al Stevens for "Another Curmudgeon Reflects" (DDJ, December 1992), an excellent counterpoint to Scott Guthery's piece. I have agonized over the switch from C to C++; while neither Al nor Scott cured my affliction, both helped me reflect more intelligently. I suspect the truth lies somewhere amidst the two perspectives. In any event, the work is appreciated--bravo!
Carson Wilson
Chicago, Illinois
P.S. It's "phylogeny," not "philology."
Al responds: You're absolutely right; I turned an old cliche into a bad joke and apparently it didn't work.
Dear DDJ,
Having recently evaluated graphical user interface toolkits for our use, it was interesting to read Ray Valdes's article, "Sizing Up GUI Toolkits" in the November 1992 issue. I, too, spent time with two of the tested toolkits, but rejected them in favor of the TEGL Windows Toolkit from TEGL Systems.
Version 2 of the toolkit, the one previous to the current one, contained everything from fast, low-level graphics routines to complete windows, menus, and dialogs, as well as a remarkably useful virtual memory manager. With full source code included, it was one of the best bargains going, at $100.00. On top of this, the technical support was, and continues to be, excellent. The current version adds support for protected-mode C compilers while continuing to support several 16-bit Pascal and C compilers.
This package has given us all that we have needed to produce applications which perform well and look good. I assume that the reason that this exceptional product was not included in your test is that you were unaware of it. Nonetheless, its omission was unfortunate.
Tim Allman
Guelph, Ontario, Canada
Ray responds: Thanks for the suggestion. If we have a follow-up article, they certainly will be included. Readers who want to contact TEGL Systems Corp. can do so at 789 West Pender St., # 780, Vancouver, BC, Canada V6C 1H2; 604-669-2577.
Copyright © 1993, Dr. Dobb's Journal