Letters

Dear DDJ,

It was with some consternation that I read Mr. Schmalzl's Letter in the February 1992 DDJ While I understand that hundreds of thousands (if not millions) of C programmers have used character arrays whose terminal element is a zero value to represent a string, one must admit the shortcomings of that method. For example, the strcpy function makes assumptions about its target representing at least as many characters as its source. Even the most diligent C programmer occasionally violates that stricture--sometimes with disastrous results. Many other C string-manipulation functions rely on the same strictures, and such a situation is obviously intolerable in a strongly typed language such as C++. In addition. as any communications programmer knows, the value zero does show up in a string occasionally, requiring the offended programmer to reimplement some of the standard functions, but with slightly different semantics and arguments.

A proper standardized C++ string class will go far to alleviate the problem. It will provide (as does the current set of C library functions) a standardized means of data handling.

Steve Teale's String class is a good beginning. Steve, however, should consider the implementation of the copy descriptor, which is a string descriptor which describes a portion or all of the storage owned by another string descriptor. The concept is implemented in hardware on the old Burroughs Medium Systems, on software via the SUBSTR pseudovariable in the IBM S/370 PL/I Optimizing Compiler, and as a combination of the two in the DIGITAL VAX VMS system.

Steve, in concert with the ANSI standardization committee, should also consider the problems associated with implementation of a class structure which mimics a native computer construct such as an int. For example, the aforementioned PL/I compiler tracks at compile time the life span of compiler-generated temporary strings and destroys them when no longer needed. In the current generation of procedural extensible languages (both C++ and ADA), this tracking must be implemented imperfectly) by the programmer at run time for nonnative constructs. In my personal version of the STRING class, the code necessary for implementation of the TEMPORARY flag (to recover storage used by intermediate STRINGS during infix operations) is approximately one-sixteenth of the code in that class. The alternative is to either prohibit complex expressions involving non-assignment infix operators, or overload the NEW operator in some ungainly way. This problem was extant in SIMULA 67, the classic ancestor of C++, and needs to be solved in an elegant fashion by the standardizers of C++ in order for the language to be regarded as truly extensible.

Doug Campbell

Culver City, California

Dear DDJ,

In answer to my letter in defense of software patents ("Letters," November 1991) you printed two letters opposing my views (see "Letters," January 1992). Roger Schlafly correctly pointed out the fact that I had erred when I stated that the Constitution guarantees inventors the right to patent their inventions. He is correct that it only authorizes the Congress to set up a patent system. However, the Supreme Court did rule that inventors could patent software and they have been doing so for ten years, so I would assert that there seems to be some legal basis for the patenting of software.

Mr. Schlafly stated that "software patents were formerly disallowed because algorithms were thought to be in the realm of abstract ideas--not because of a lack of utility." I believe that the understanding of the word algorithm may be the problem here. It could be that programmers understand the word in a broader sense than they should. I do not know. I do believe, however, that it would be at least as useful for your magazine to publish an article by a competent legal authority on this subject as it was to publish the argument in opposition.

Mr. Schlafly asks "does anyone seriously think any patents have promoted progress?" Though he is referring only to software patents, the question as stated is appropriate. The countries which have had the best patent systems have been the ones with the most dynamic economies. The United States has long been the envy of the world in this regard and has afforded the lone inventor the greatest protection. The Soviet Union granted no property rights to inventors. Yes, I do believe that patents have promoted progress. And those for software will continue to do so.

I stated in my previous letter that I had invented a more efficient method of displaying text on a computer screen. Mr. Gallagher shows through his derisive attack upon me that not only could he not see the problem and its solution, but when a problem was suggested he failed to even imagine what it might be. The patent he would deny me might help to guarantee compensation for the efforts I have made in the past to develop a mind which is able to invent and the effort needed to develop this particular invention. Is my invention of value? Only time and great effort will tell. The protection of a patent will surely encourage my efforts.

Howard R. Davis III

Atlanta, Georgia

Dear DDJ,

The issue of software patents is a simmering problem which I fear may ultimately kill what remains of the U.S. microcomputer industry. For the past two decades, various bits and pieces of the industry have slowly vanished, being taken over by Japanese and other Asian companies. Now all that remains of the industry are microprocessors and software, and microprocessors depend on the large installed base of software. Oh sure, there are a few semiconductor manufacturers hanging in there, and there are a couple of hard disk manufacturers, but they don't represent very large shares of their respective markets.

What I fear is that five to ten years from now, large U.S. software publishers (who will probably hold most of the software patents) struggling against increasing competition will resort to patent infringement lawsuits as a means of raising revenue. (Just look at Apple!) These lawsuits will virtually kill software innovation in this country. (Can you imagine what Lotus or Microsoft products would be like today had there not been competition from upstart companies like Borland?) This will allow foreign software publishers to become the source of software innovatuon. Once that happens, it won't be long before foreign companies can take control of microprocessors as well. And that will be the end of the U.S. microcomputer industry.

Dave Eriquat

San Francisco, California

Dear DDJ,

I read with great interest your November 1990 article, "Software Patents," and the ensuing letters it generated. While I agree with The League for Programming Freedom that the granting of absurd patents hurts software innovation, there still is room--nay, a requirement--for patents and copyrights.

Part of the problem is that patent law can't keep up with the rapid advances in technology. Jerry Saunders, chairman of Advanced Micro Devices, was quoted as saying that, "If cars evolved at the rate of semiconductors, we would all be driving Rolls-Royces today that go a million miles an hour and cost 25 cents."

The problem with patents is that they last for 17 years. In "slower" industries, this allows a company to recoup its costs of research and development, and to make a profit. Upon expiration, the patented item is still likely to be useful to competitors. Does a 17-year patent, however, make sense for an industry that can make itself obsolete in fewer than five years? Instead of saying no to patents, perhaps for computer hardware and software, we should propose a reduction in the patent's term.

Another part of the problem is our confusion as to what should be patented and what should be copyrighted. While it's accepted that underlying source code can, and should, be copyrighted, lawsuits by Apple and Lotus ask if "look and feel" can be protected by copyright law. Opponents provide analogies comparing software to books, or to the layout of an automobile's instrument panel, arguing that the ubiquity of these interfaces make them property of no one. Perhaps.

I don't think we should copyright "look and feel." I do, however, think we should patent "look and feel" under a reduced term. Copyright law protects expression--complete works--something with a beginning, middle, and end; a story rather than a sentence, a dance number rather than a pirouette, a spreadsheet rather than an interface. When determining whether to patent software or to copyright it, we should ask ourselves if the code by itself does anything. For example, a sorting algorithm by itself does and expresses nothing in the sense of a complete work and should not be considered for a copyright. A patent would be more appropriate. Similarly, a user interface by itself does nothing. In contrast, a user interface endowed with sorting capabilities can do something, and marks the beginnings of expression which can be copyrighted.

It was unfortunate that silly patents were approved, and I agree that no more patents should be granted until competent lawyers and programmers are involved in the process, and until the patent law is amended to accommodate the rapid change in technology.

Michael Yam

New York, New York

Dear DDJ,

I take exception to Tim Cooper's statement in "Letters," February 1992 that "MS-DOS ... is the Fortran of operating systems."

I am no fan of DOS, and putting Fortran into the same class as DOS shows a lack of computer history. Whereas when DOS came out it added nothing to the world of operating systems, when Fortran arrived on the scene it brought incredible advances to programming. Among these was the development of the object library. There was no longer a need to recompile every module, which is what C still does with its insipid include statement. Granted, some Fortran compilers have this function too, but a good working library does not change enough to warrant recompilation for every program. Nor would one want to recompile, considering the size of some libraries. And I know that object libraries are machine dependent, but hardly any code is fully transportable from one compiler to the next. Each manufacturer has their own little extension to the language that makes it a headache to transport code.

DOS exists only because the original PCs lacked the power, RAM, and hardware necessary to have an advanced operating system. Fortran exists because it made programming simpler. DOS will eventually die out, but with the new Fortran standard definition it is just possible we will see a resurgence in Fortran, as old code is brought up to today's more powerful processors. Fortran is no longer the spaghetti code you were taught in school.

Which brings me to a request: Could you enlighten your readers to the new Fortran standard definition? I think most will be quite surprised.

Denys Tull

Cincinnati, Ohio

Dear DDJ,

In the March 1992 "Programmer's Bookshelf" column, Ray Duncan covers a number of books that detail the history of the personal computer industry. Computer history being an interest of mine, I have a few more books to add to the list:

• The Devouring Fungus, by Karla Jennings (W.W. Norton, 1990), is a humorous look at computers and the people involved with them. It has many tales and stories from the early computer days up to the present--a few classic stories and a few new ones. The book can be found in the Humor section.
• Fumbling the Future: How Xerox invented, then ignored, the first personal computer, by Douglas Smith and Robert Alexander (Quill, 1988). The title pretty much covers the contents of the book. A good portion of the book details the business aspects of the Xerox Alto, but there is an interesting section covering the technical aspects of the development of the Alto. This title is found in the Business section. As an aside, the Smithsonian has an Alto on display in the Information Age exhibit.
• The Computer Entrepreneurs: Who's making it big and how in America's upstart industry, by Levering, Katz, and Moskowitz (New American Library, 1984). Short articles on over 60 people involved in the personal computer industry. Covers persons from famous companies like Atari, Apple, and Kaypro, and from not-so-famous companies like Human Edge Software and Wicat Systems. Included many of the early companies and personalities.

Alexandria, Virginia

Dear DDJ,

I take exception to Michael Swaine's referral to Cobol as a dead language ("Programming Paradigms," October 1991). I had programmed in Fortran, Basic, and dBase before learning Cobol two years ago. I have been reviewing C++ more recently. Of these languages, I prefer Cobol for the following reasons:

• Well-written Cobol is easily readable and allows assisted review by nonprogrammers who are expert in what the program is trying to accomplish.
• By requiring predefinition of all variables, unwanted variables created on-the-fly through misspellings need not be a problem. This is a problem with Fortran, Basic, and dBase.
• Through the use of COPY files, Cobol lends itself well to the use of data dictionaries common to all files.
• Modules written in other languages can be linked to Cobol programs and called as subroutines. Thus, the best language for a given task can be used with the Cobol program doing the overall coordination.
• Cobol's lack of ability to address system resources directly serves as a safety feature in complex safety-critical applications; one does not have to worry about a Cobol program interfering with other software.

I do use other software tools when I program in Cobol. But this reflects a valid notion that one uses the best tool for the task at hand. Because I use these tools with Cobol does not mean that I can use them in place of Cobol.

As a physician, I can assure you that brain death means lack of brain activity. As a highly active systems analyst and programmer. I can assure you that there is plenty of Cobol activity, at least in our institution. Thus, reports of Cobol's demise are premature.

Stephen J. Levine, M.D.

Oklahoma City, Oklahoma

Copyright © 1992, Dr. Dobb's Journal