Dear DDJ,
Thank you for mentioning the Amiga in your article "Dr. Dobb's Journal Excellence in Programming Awards" (DDJ, March 1996). When I saw the name of my computer-of-choice next to the names of those big-named systems, I was beside myself. Those were ten letters that you didn't have to put in your article (well, 15, if you count the commas, spaces, and the hyphen) but, you put them in anyway.
I know it's silly to be happy about something like that but, after the Commodore bankruptcy, I thought the Amiga might disappear from the face of the Earth. Hopefully, Amiga Technologies will be able to resurrect this fine machine.
Maybe some day articles on AmigaDOS message passing will sit next to articles on Windows message passing in your magazine.
Michael S. Sage
Amherst, Ohio
aa5964@freenet.lorain.oberlin.edu
Dear DDJ,
Al Stevens' "C Programming" column about Quincy 96 (DDJ, February 1996) sounds like a worthwhile project and I hope he continues extending it as mentioned to include some AppWizard/ClassWizard functionality. Example code is always of great help to developers working on development environments for their tools.
Al mentions that "no one has licensed or ported MFC to GNU C++" (page 126). I should comment that my company offers a library called WM_MOTIF that allows developers to use MFC applications on the more popular UNIX environments. Ads for the library have appeared several times in DDJ over the past year, so you might have read about it. As part of that product, we provide the necessary changes to use MFC 2.52 and 3.1 with g++ (4.0 by February 1996). We do not include the Microsoft source code, only our changes applied automatically via a patch program. I believe two other companies also offer support for MFC under g++, with Microsoft's blessing. Information about our WM_MOTIF library and the WMMPATCH utility is available from our Web site (http://www.uno.com).
When you extend your IDE further, you might consider porting it to Linux using a "Lite" version of WM_MOTIF. Requests for IDE functionality for gcc/g++ appear frequently on the Linux USENET groups (particularly comp.os.linux.development.apps).
Jesus Alvarez
jalvarez@uno.com
Dear DDJ,
Thomas Nielsen's letter on majority rule (DDJ, February 1996) prompts me to recommend the book Beyond Numeracy: An Uncommon Dictionary of Mathematics, by John Allen Paulos (Random House, 1991).
Beyond Numeracy contains a chapter addressing which voting system is the fairest, giving an example of 5 candidates and 55 voters. It turns out that there is a voting system that suits each candidate; that is, choose the voting system and you have chosen the candidate. This is not an academic exercise because here in Italy the political parties have been fighting for years to get their own voting system used, each of course wanting the one that gives them the most points. The other chapters in Paulos' book will be of interest to programmers, too.
Owen F. Ransen
rans001@IT.net
Dear DDJ,
I loved your March 1996 issue. Keep up the good work. However, I disagree with a couple of sentences in Al Stevens' "C Programming" column. I know it is an opinion column, and he is entitled to his beliefs, but I object to serious journals, such as DDJ, spreading disinformation. Al writes:
Will such 3-D visual programming environments eliminate the need for programmers to understand source code as we know it today? Not likely. C++ and Visual Basic have not eliminated assembly language. Or machine language, for that matter. In the future, when all else fails, you will look at an occasional memory dump, stack pointer, and interrupt vector, just as you do today.
While I do remember looking at core dumps--back when they were from little donuts of magnetic material--I have not looked at one in at least 20 years. I can agree that for some small set of serious gurus, looking at the entrails of our programs may occasionally be informative. I believe that for most professionals using modern tools, there is no need.
More importantly, I think journals such as DDJ have a responsibility to educate developers that hand-coded assembly programming has no place in modern systems. RISC systems, and RISC-like CPUs such as the P6, rely upon intelligent optimizing compilers to keep their pipelines full, their registers renamable, and the performance at the level claimed.
It is simply impossible to optimize more than a handful of assembly instructions. Yet the PentiumPro (P6) has a 14-stage pipeline and three execution units. To have all of these parts working at rated speeds takes at least 17 stages of continuous work. Achieving the advertised performance takes a continuous stream of hundreds of optimized instructions.
Computers (compilers) are good at repetitive calculations. Humans would go crazy from boredom before optimizing a meaningful amount of code. The next generation of CPUs from Intel and HP will use VLIW technology. This will further strengthen the demand for optimizing compilers. Hand-coded assembly language is dead for all but embedded systems. DDJ's readers should be getting this as a consistent message.
By the way, it will be interesting to see how interpreted languages such as Java, Smalltalk, and Visual Basic work on next- generation CPUs.
Pat Farrell
Fairfax, Virginia
http://www.isse.gmu.edu/students/pfarrell
Al responds: Core dumps? I haven't looked at a core dump in years either, but I look at RAM dumps almost daily. I wonder how fortunate I would think myself to have been spared the rigors of assembly language, memory dumps, register contents, and such for 20 years. You might view it as a blessing; I would take it as a hindrance. Most contemporary debuggers allow us to view registers, memory buffers, and machine-language code unassemblies. Those debuggers are in the toolsets of virtually all programmers, not just for the so-called gurus. Those features are there because we need them. That need is not likely to go away any time soon.
Dear DDJ,
In your April 1996 issue, Al Stevens talks about getting programmers out of the closet so they can know when the insulation is not installed because the wiring's not done because the plumbers have not finished. His suggestion that programmers work in a virtual environment to make this possible ignores some more pressing problems in software development. The team must first learn why the wiring must be done before the insulation.
Having changed employers more frequently than I care to admit, it has become clear that each business regards its product as unique. The theorists in our business are studying "patterns" as the newest trend in software development. The patterns have existed all along, it was EGO that refused to see it.
chermann@cris.com
Dear DDJ,
Andrew Binstock's article "Hashing Rehashed" (DDJ, April 1996) was interesting and timely, as I just finished writing a portable hash-table class for a project last month. Along with the square-root article and "Swaine's Flames," this was quite the issue!
While inspecting the PJW and Elf algorithms to see which one might be the most appropriate for my class, I kept noticing something interesting. If sizeof( int)==sizeof( long)==4, the algorithms are identical. Just now I ran them both through UNIX's /usr/dict/web2 and web2a, and indeed they always return the same results on my 32-bit system.
Now, off to determine whether an expandable closed table would be appropriate for this class....
Scott Hess
Burnsville, Minnesota
shess@winternet.com
Dear DDJ,
I read with much interest the article "Hashing Rehashed," by Andrew Binstock (DDJ, April 1996). Andrew presents a decent article, however, I have an additional recommendation.
First of all, searching through a linked list can be, at worst, O(n) in efficiency. This is due to the fact that it is possible, with an inefficient algorithm, to produce a "hit" on the same hash value numerous times. Instead of using a linked list to store the data off of the hash table, I suggest using a binary tree. That way, even if the hash function is poor, the binary tree will still return O(log2 n) access to the stored data. This is relatively easy to accomplish. Instead of the array or table pointing to the head of the linked list, change the table to point to the root of the tree. This, in addition to being a near-perfect hashing algorithm, will produce speedier results.
Brigham W. Thorp
West Simsbury, Connecticut
Brigg999@aol.com
Dear DDJ,
Bravo for Thor Mirchandani's article "Building Parsers with Leopurd" (DDJ, March 1996). I have seen too many software projects in which the use of LEX and YACC resulted in size, speed, and compatibility problems. Top-down parsers of the type that Thor describes are very simple to program and maintain. They can easily be an order of magnitude smaller and faster, because they don't have to wander around in all those big tables, and they don't have to build parse trees.
I believe there is one mental block that prevents many programmers from programming and using top-down parsers. It is the idea of one-token look-ahead. I think look-ahead is counter intuitive because it means you scan in the next token immediately after accepting the current one, rather than immediately before. Many algorithms can be simplified by using look-ahead, not just parsers.
Mike Dunlavey
Needham, Massachusetts
miked@mga.com