Letters

Dear DDJ,

These notes were prompted by "Crotchet No. 5: The Great Debate" in the October 1988 DDJ ("C Programming" by Al Stevens) and are offered in the spirit of thoughtful contemplation as to what the hell we're supposed to be doing and how the hell we should best achieve it. Others may have different views!

Systems analysis is the distillation of a user requirement into a programmable specification. In my experience, the whole process seems to reduce to the following two fundamental precepts: 1. Derive and understand the concepts and rules by which data objects may attributed, operated on, and related to other objects to produce a meaningful end result. 2. Maintain and know how to use a set of tools, libraries, and techniques to enable the crafting of the masterpiece.

I think most people would agree that the use of these precepts is regarded as a skill. These precepts, however, are more general than they seem. With suitable generalizations they may be applied to any engineering discipline and indeed to any traditional art form.

My dictionary describes "art" as "skill applied to imitation and design." Thus, a program does not need aesthetic quality to be art. Assuming the above precepts are valid and that a program is the medium of an analysis much as a painting is the medium of an expression, then programming is an art.

The definition given for "aesthetic" is "appreciated as having beauty." I regard (nearly) all my programs as things of beauty! More importantly, I generally regard other programs as things of beauty if well-crafted. Thus, programs have aesthetic appeal; what comprises that appeal in a program could be (and has been) argued over at length.

Furthermore, the definition given for "science" is "the pursuit of systematic and formulated knowledge." Programming, being the application of defined knowledge, is thus not a science. The development of the rules of programming, however, may be regarded as such by this definition. Hence the apt term "computer science" describing the formulation and pursuit of programming knowledge.

Thus, I would argue that computer science is a true science that involves the formulation and pursuit of programming knowledge using the art (application) of programming (software engineering) to help develop and impart that knowledge.

Tomorrow I will, as Douglas Adams said (roughly), "go on to prove that black is white and get run over at the next zebra crossing!" This argument can be generally applied to other disciplines, as in chemistry as a science and chemical engineering as its application. And yes, programming is a discipline even though its practitioners may not be!

Now we come to the process by which the analysis may be turned into a useful program. To this end, programmers will have at their disposal an array of tools and libraries that implement general concepts to allow construction of specific code. In C this will typically be achieved by making a set of structures (objects) with sets of attributes (fields) and writing/using a set of routines to operate on and relate the objects.

Object-oriented programming tools are designed to partially automate and so make more reliable the process by which the analysis is turned into operating code. C++ is one such tool. It attempts to allow the programmer to think and work in the context of objects, attributes, and operators rather than having to translate them mentally into structures, fields, and routines.

Additionally, maintenance is simplified because object-oriented programming imposes greater control over the scope of the code and the type of the objects. Interestingly, this is exactly what Pascal attempts to do; however, its scope and type rules are bound into the language thus, severely restricting its usefulness. A language, such as C++, allows programmers to define a set of type and scope rules according to their applications. The compiler then enforces these self-imposed rules. This is exactly what we want!

For this, programmers have to think harder and more clearly. The extra effort pays off in reduced debug and maintenance time. The concept of increasing abstraction is vital to code generation and maintenance cost-effectiveness. In days gone by the simple goto was used to implement all sorts of wonderful conceptual constructs. Structured programming languages evolved to formalize and automate some of the more common of these constructs to provide concepts such as repeat, while, and so on, using machine code gotos for their implementation. Similar arguments apply to every keyword that any language employs. Ratfor was a good early example: Pascal and C have persisted longer and further.

Dear DDJ,

I've wanted to write this letter for a long time, but haven't had time to put printhead to paper. It seems that Dr. Dobb's is getting further and further away from the kind of programming that really matters, and more and more into obscure research topics in computer science.

Where I work, milliseconds are important. What matters is how many messages you can process in ten milliseconds. And it's never enough, so you go back and sweat over the code. Believe me, 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. To get speed, you don't distance yourself from your data -- you've got to get down and dirty with your data. The guys who are fighting the war are not the generals in the hotel rooms with their sparkling white maps and military icons, sipping tea from Wedgewood china. No, they're the guys in the trenches, with their buffers and flags and registers.

Now what audience are you going to write for? Do you want to be the Vogue of programming? The National Enquirer? Cosmopolitan? Gee, you used to be more like Popular Mechanics. Just remember, there are a lot more privates than there are generals. And Popular Mechanics had Mimi, too.

Rick Rodman

Manassas, Virginia

DDJ: Gosh Rick, we've always been more comfortable in the trenches than the hotel rooms and our approach continues to be more Popular Mechanics than Scientific American. We write for the serious programmer -- as evident by the hundreds of lines of source code we publish in each issue -- and, by sharing faster, better, smaller programming techniques that solve today's problems today, DDJ will always be a hotrodding magazine for programmers. But we also have a responsibility to lead the way as technology evolves. Five years from now, programming won't be the same as today, just as today's environments are different from those five years in the past.

Dear DDJ,

I just received my second copy of DDJ and my comment on memory limitation is that about the time the technical limitations were overcome, they were replaced by the corporate money-grubbers who, with the wholehearted cooperation of Congress, replaced the technical barriers with a cost barrier. I am convinced that about half of the impediments to progress could be cured by shooting all corporate accountants. Shooting all corporate lawyers wouldn't hinder solving the other half of the problems, either.

I am not (at least as yet) a professional programmer. I'm just a hard-core electronics nut just getting into his second half-century of obsessive interest in the field. I was a professionally trained repair technician back in the 40s and 50s, but I found other work when transistors and PC boards came on. What I know about computers and programming comes from self-education and I'm still learning. Diving into Dr. Dobb's Journal was a little like wandering onto a nude beach by accident -- a little shocking like any transition to a new environment, but stimulating and educational.

Billy R. Pogue

Lake Havasu City, Arizona

Dear DDJ,

I would like to describe a case of superlinearity in a computer with parallel architecture, that will not look like magic to Michael Swaine.

We need to search a disordered space of 10 million strings to see whether it contains a particular string. With a single processor, we examine string 1, then string 2, and so on, until we find a match or until all strings have been examined. But with ten parallel processors, we conduct ten searches simultaneously, with the i - th processor beginning at string (i - 1)*1e6. This parallel search will be complete in one million steps.

Now let j be a multiple of one million, and let x be any number less than one million. If the given string is to be found at location j + x, then the sequential search would take j + x steps, and linearity would require (j+x)/10 steps. The parallel search would take x steps. Clearly, superlinearity would raise its mystic head whenever (j + x)/ 10 > x (about half of the time).

Phil Geffe

(Consulting Engineer)

Cincinnati, Ohio

Dear DDJ,

My new issue of DDJ arrived today and it's the first really good programming related thing to happen in a week. As usual I read the "Programming Paradigms" column first. Well, Michael Swaine, you have become the apple of my eye. I have been screwing around with a major database crash at the site I contract with. The reason it has been a problem for a whole week is that most of the folks involved are victims of the current educational system's method of teaching programming. They are, unlike myself, company employees who, if they can't find some techno jargon to hide their screw-ups, will face spending the rest of their careers in a somewhat lesser department without rapid advancement, but not termination by any means. All of them are folks who cannot get beyond "what de book say," and down to the real problem: Trouble with paradigms.

Memo writing is a much more coveted skill than that. I will go one step beyond praising your idea regarding the proper method of educating programmers, and say that anyone who thinks that the real job of programming is to "write a little code" should be shot. The second course the people will need (CS102 I guess), is healthy skepticism. (Odd that you should have mentioned that in your column also ... everything seems so clear at 3 a.m., ya know?)

There is an absolute need for more programmers, but not for more folks who are seeking "good clean work with no heavy lifting." What is needed is a crop of grunts who really love this crap.

Robert L. Hume

CompuServe: 71220, 1066

Dear DDJ,

I own an Amiga and was wondering if you could cover this computer in your magazine. I still enjoy reading your magazine (even though it seems to be for IBM only). If you started covering the Amiga, I would subscribe to your magazine in a second!

Matt Childress

Holland, Michigan

DDJ: We hope the article by Chuck McManis fills the bill, Matt.

Dear DDJ,

I enjoyed and appreciated your editorial in the March '89 issue of Dr. Dobb's. I agree, professionals should be held responsible for the precise sculpting of their product. However, I don't agree that education is not the solution to the pirating problem.

Mr. Gillette's idea of embedding a serial number in the bios of each machine is a good one and one I've wondered about myself. Why don't manufacturers do that? The problem is that even if a serial number was available, any software protection scheme would add another layer of complexity to the development and support of a software product. For example, how do you handle hardware upgrades where the serial number would have changed?

This complexity "buys" the developer very little protection against even a moderately experienced computer user. All that needs to be done to subvert the protection is copy the original disks before installing on the target machine.

As Nancy Reagan discovered in her work against drug abuse, jailing the distributor isn't completely effective. As with drugs, the way to stop software pirating is to make it unpopular to do. Maybe we can license their slogan, "Software pirating.... Just say no!"

Tim Deardeuff

Provo, Utah

Dear DDJ,

I want to pass along a couple of thoughts I had regarding your March [Paradigms] column. Writers should indeed be held to high standards. All too much writing in the computer field is turgid, hackneyed, rambling -- you name it! I too am a writer, and always strive (with varying degrees of success) to produce work that is clear, concise, and literate. Knowing how difficult the task can be, I am doubly appreciative when I find those qualities in the work of others.

Copyright protection for software does remain a problem, but the serial number technique that you mention has at least two serious flaws. For one, it makes no provision for people or businesses that upgrade their computers while keeping old software. Nor would it be acceptable for people like myself, who use different computers in different locations. Each software package that I purchase is installed on all of my computers; the manuals are schlepped back and forth as needed. No one but me ever uses any of these machines. Surely such an arrangement is within the spirit, if not the letter, of software licensing agreements. The serial number scheme, by tying a program to a single computer, would prevent me from using my software in this fashion.

Software copyrights need to be protected, but serial number keying is not the way.

Peter G. Aitken

Durham, North Carolina

Dear DDJ,

Let's not overstate the usefulness of run length encoding. Robert Zigon is correct in pointing out ("Run Length Encoding," February 1989) that RLE is simple, fast, and elegant, and I have no doubt it works magic on Mr. Zigon's frame-grabber data, a type of data for which it is ideally suited. But RLE will not work on English text, and its usefulness in compacting object files is next to nil.

Don't get me wrong; the article itself was good. The author did give the impression, however, that RLE will compress a wide variety of file types by 20 percent or more. In fact, it will make most files grow, and any file (such as an .EXE file) that contains all, or nearly all, 256 ASCII byte values will need switchout codes and exception-handling to account for switchout codes, over and above Zigon's simple routine.

Kas Thomas

Stamford, Conn.

Dear DDJ,

The article by Robert Zigon, (February 1989, page 126), caught my eye, but unfortunately I cannot use it. The problem lies in the fact that the English language has very few "double" letters in the words. I went through some 200,000 bytes of English prose to find out how many characters are the same right after each other. The average is about 2 percent. Some other languages like Dutch or Finnish have a much higher value, e.g. Dutch about 5 percent, and Finnish also about 5 percent. In any event, even for those languages the output file would about double, rather than be compressed.

Paul A. Elias

Fountain Hills, Arizona

Eds: RLE is applicable chiefly to the compression of data that has a high degree of redundancy. RLE works great, for instance, with graphics data where there are many consecutive bytes, all having the same value.

Please note the following required changes to the TSRUnit in "Creating TSRs Using Turbo Pascal" by Ken L. Pottebaum (May and June, 1989).

  Line 87   Our26 = Our25+27;
       88   Our09 = Our26+27;

The INLINE code changes are to byte number 13 in OurIntr25 and OurIntr26, which are interrupt intercept routines contained in PROCEDURE Asm. Change OurIntr25 to:

  { 13} $68/>Our25+19/   { PUSH Our25+19   ;Clean up stack with-  }
         $C2/$02/$00/    { RET  2          ;out changing flags.   }

Make a similar change in OurIntr26 so that it becomes:

  { 13} $68/>Our26+19    { PUSH Our26+19   ;Clean up stack with-  }
         $C2/$02/$00/    { RET 2           ;out changing flags.   }

Also in June, Jim Mischel reported one change to his article "Writing AWK-like Extensions to C." In Listing Three, page 94, the line that reads:

if (makepat (fs_DEFAULT, pat) = = NULL)

should read:

if (makepat (fs, pat) = = NULL)

Copyright © 1989, Dr. Dobb's Journal