Dear DDJ,
We were all shocked to hear about the death of Kent Porter. Having seen him so recently at a press conference made the news all the more incredible. What can we say?
As an industry leader, a writer, programmer, and technical editor, Kent taught us a lot. His opinion was respected. He inspired us. It's hard for us to believe he's not here. Little things, like leafing through Dobb's only to stumble across the "Graphics Programming" column, become painful reminders. We remember how precious life is and how seldom we stop to appreciate those around us -- both coworkers, and friends -- for the special people they are.
This is hard for us in many ways. Most of us know Kent through his words. We learned about the intricacies of VGA graphics while we laughed at an anecdote about Kent's wife having a salesman match wall paint against her wet washcloth. We can't pick up a copy of Turbo Technix without seeing Kent's name. His wide range of interests and his good humor made his appeal broad. Whether we are interested in C or Pascal, bezier curves or binary trees, we always find Kent teaching us something.
We shared a common vision with Kent and each other that has bound us since the early days. We saw the world around us changing and felt we had a hand in those changes. Computer Lib, Dream Machines, the Community Memory Project, and the People's Computer Company, with Dr. Dobb's cheering us all on from its leaves of scratchy newsprint. We never minded that Dobb's looked more like the first Whole Earth Catalog than the slick and polished journal that would lead a revolution, changing the way we work and play forever. We thought that we could do anything. Through our intense commitment and energy we could shape and build a world that our parents and our parents' parents couldn't even imagine.
Kent's death brings us back to earth. Dreams are smashed, a friend is lost, we remember our mortality. Tributes, like funerals, are for those left behind. We don't know how to ease the way we feel about Kent. Maybe for a moment we can put aside the petty rivalries and the intense competition, and remember that we all live now on a tiny planet, in the global village that shrinks daily in size. And maybe we can remember that the greatest thing we can do for our friends is appreciate and affirm them now when a kind word can carry them through a hard day rather than waiting until our voice can no longer be heard.
We will miss Kent.
Philippe Kahn
Greg Voss
Robert Dickerson
Anders Hejlsberg
Dick O'Donnell
Tom Wu
Gene Wang
Brad Silverberg
David Intersimone
Gary Whizin
Rick Shell
-- Borland International
Scotts Valley, Calif.
Dear DDJ,
When I read the letter from Mr. Rick Rodman in the "Letters" column (DDJ, July 1989), I was surprised. I enjoy the bit-twiddling articles just as much as the next reader. However, I feel that there are options other than bit-twiddling and that they should be explored in a forum such as DDJ.
I disagree with Mr. Rodman's opinion, "... all those object-oriented paradigms aren't worth a plugged nickel in the real world. All that structured programming data abstraction is the wrong way to go, too." Those statements are very general. While those techniques have been shown to improve many aspects of programmer productivity, they are not necessarily useful in every situation and may not produce shorter program execution times. Perhaps the type of environment he is working in would not be suitable for the use of structured, object-oriented, or other advanced techniques.
I enjoy the current format of DDJ very much. I applaud the addition of the "Graphics Programming" column, the OS/2 coverage, and the coverage of other environments such as the Mac and Amiga. I am looking forward to the coverage of OOP in general and Smalltalk in the "Structured Programming" column. I always manage to read my copy of DDJ within two days, starting with "Swaine's Flames," of course. I just can't put it down! Keep up the good work!
John H. Critchfield, Jr.
Duenweg, Missouri
Dear DDJ,
In addition to Al Stevens' discussion of the Control-Break abort handling with Microsoft C in the February issue, here is a version of Al's keyhit( ) function that is purely written in MSC and therefore doesn't require MASM to be compiled.
The following version of keyhit( ) uses the ROM BIOS keyboard buffer head and buffer tail pointers: If the pointers are equal, no input from the keyboard is pending; otherwise, a key has been pressed and its ASCII value put into the keyboard buffer by BIOS. The pointers are located in the BIOS data area at 0040:001A and 0040:001C, and can easily be accessed using Al's peek( ) function. Here's all there is to it:
int keyhit(void)
{
return(peek(0x40,0x1a)!= peek(0x40,0x1c));
}Ralph Langner
Langner Expertensysteme
Hamburg, W Germany
Dear DDJ,
Metz's response to Mohr's flames (DDJ, June 1989) seems to me to have missed the most important lesson inherent in Mohr's commentary: When we ignore history, we are condemned not merely to relive it, but to suffer living in an inferior version. RT-11, and its big brother TOPS-10, are well-designed operating systems that run on well-designed hardware. They owe their success to a combination of features that are much too rare in today's micro world:
Although some of these features have been incorporated in micro operating systems, I've yet to see anything that approaches the seamless implementation of the DEC products. And let there be no doubt that the quality of the operating system strongly affects a programmer's productivity. Over a period of some twelve years, I watched a shop running TOPS-10 outproduce a neighboring shop running VM/CMS, typically by a factor of about ten to one. Can we afford to discard such capable tools?
Similar arguments apply to TECO. Yes, Borland's integrated programming environment is cozy, but on the whole, full screen editors waste too much time in navigation and screen painting. For a simple demonstration, try a global search and replace with CP/M's ED, and then do the same job with Wordstar. It's faster to copy a large DOS file to a CP/M disk, do the replacement with ED, and then move the file back to the DOS machine.
ED is, of course, a greatly simplified version of TECO. It lacks TECO's conditionals, flow control, Q registers, pushdown list, bounded searches, wildcard searches, etc. TECO is as much a programming language as an editor. A small subset of TECO is adequate for a majority of editing jobs, but very powerful tools are available whenever they are needed. And although TECO is an extremely terse language, most of the commands have highly mnemonic one-or two-character "key words."
One of the Mohr important points in Doug's letter is that a program as powerful as TECO can run on a machine as small as a 64K PDP-11. In the CP/M world, ED wastes quite a bit of memory because it was written in a high-level language, but it still runs in less than 8K. An assembly language rewrite could roughly halve the RAM requirement, leaving plenty of room for some of the more esoteric features of TECO. I know of at least two people who were convinced that writing their own versions of TECO for DOS machines was a sound investment in future productivity, and I am currently working on a version for CP/M.
On a related subject, Jeff Duntemann's column in the June issue leads me to wonder why, after all these years, we still toy with clever kludges instead of coding the obvious calendar algorithm. Granted, the calendar display was intended only to illustrate screen management techniques, but as Jeff himself asks, is this angst really necessary? Given a suitable choice of offset for the year, 16-bits will hold 179 years' worth of days, and whose code will survive that long? Jeff's simple function to test for leap years (certainly justified in this application) suggests that he has no such expectations. Why not stick to integer arithmetic? If one really needs an archaeological time scale, a LONG-INT will handle five million years. And in making the primary test for leap years, one can save a few machine cycles by coding
IF (Year AND 3) = 0 THEN
Is LeapYear:= TRUEIf the full leap year algorithm is required, this logic can be applied twice, once before and once after dividing by 100.
And finally, endorsing Mark Pickerill's views in June "Letters," do we build bigger and faster machines, not because we need more computing power, but because it's more comfortable to repeat the familiar mistakes than to risk making new ones?
Yours for the more efficient use of resources.
Arpad Elo, Jr.
St. Johnsbury, Vermont
Dear DDJ,
I have decided to renew my subscription to Dr. Dobb's solely on the basis of Michael Swaine's interview with Hal Hardenbergh. I have followed him over the years through DTACK Grounded, and have always admired him for the fact that (as I knew the facts) he was right MOST of the time. This, for a writer, is quite a record and generally unsurpassed by any other writer whom I read in the computer field.
He is a first-rate engineer, clearly, and I cannot say the same for any other engineer who writes for the public. It was a pleasure to see his existence recognized by Dr. Dobb's, does this mean Dr. Dobb's is "cutting through the crap" also? I can now hope to learn more about AI through Hardenbergh's incisive analytical powers: either in Dr. Dobb's or Programmer's Journal.
Swaine's was a very good interview -- keep up the good work! Maybe there is hope after all.
John Griffith
Yorktown Hts., N.Y.
Dear DDJ,
In the July DDJ "Letters" department was a letter entitled "Superlinearity without Mirrors." Phil might not be using mirrors, but he is certainly using slight-of-hand [sic]. The example he described is not a demonstration of superlinearity, but a reasoning fallacy.
Reviewing the example, Phil says that one processor will require (j+x) steps, and ten processors will require x steps per processor, or 10x total.
But this has nothing to do with multiple processors, and everything to do with the fact that he changed the search order. If he had one processor searching the first element in each of ten partitions, then the second element in each, etc., he would get the same results as his multiprocessor system. Likewise, if his first processor gets elements 0, 10, 20,... the second gets 1, 11, 21,... etc., he would get the same results as his uniprocessor.
The point is that the location of the match is random. What he actually demonstrated is that for some values, searching in one order will find the value sooner than searching in another order.
It does not matter what order is used, since they all average out anyway. So you will use a search order that minimizes the overhead of the search.
John M. Dlugosz
Plano, Texas
Copyright © 1989, Dr. Dobb's Journal