Dear DDJ,
I read Ray Duncan's historical book review ("Programmer's Bookshelf," March 1992) with amazement. He feels Richard Stallman is an angry iconoclast tilting at windmills. Mr. Stallman writes the finest C compiler I've ever used (and I've used more than a dozen). In the GNU Manifesto, Mr. Stallman writes, "I consider that the golden rule requires that if I like a program I must share it with other people who like it." I agree with this attitude: It is much easier and more productive to give away software I've found useful to other computer users.
Mr. Duncan says, "At present, he is furiously rewriting a 20-year-old operating system so that he can give it away to spite AT&T--while the rest of the world moves on to new operating system architectures, new programming paradigms, and new user interfaces." But with low-cost workstations, everyone is adopting UNIX and going away from proprietary architectures, which Mr. Duncan seems to be endorsing. What is newer is not necessarily better. X Windows, a networked graphical standard, runs well on modern processors running UNIX. X Windows is freely available in source form, and is an excellent example of programming.
I do agree with Jeff Duntemann's March "Structured Programming" column. It is fundamental that the problem be understood in the analysis. (It is useful if the implementor has the problem.) I agree that clear text is always more useful than a lot of meaningless diagrams. I've also found very good software writers are normally quite good English writers--both share language.
Arpad Elo's letter in the March "Letters" column also raised a useful point. The point was that current technology is worse (I think it is much better), but in order to reuse something, one has to know it exists. While the complaint is registered that linking an empty program requires 30 seconds, this is only the case with this system, not necessarily the general case.
In the same issue, Michael Swaine raises the point in his "Programming Paradigms" column that "anything a small company can do, a well-managed large company can also do." I disagree. Companies don't write programs, people do. Most successful software companies are started by excellent programmers. As they grow, it is much more difficult to find these talented programmers.
Marty Leisner
Rochester, New York
Dear DDJ,
While Ray Duncan has a right to his opinion of the GNU project, I would like to correct certain statements that are simply inaccurate.
The purpose of the GNU project has nothing to do with spiting AT&T. Even AT&T does not regard GNU in this light; in fact, Bell Labs has provided support to the Free Software Foundation. We are angry at AT&T now because of its patent threats against the users of X Windows, but until this began, GNU developers felt no particular enmity for that company.
The actual purpose of the GNU project is a positive one--to give users freedom. Specifically, free software gives users the freedom to study, share, change, and improve the software that they use. In 1983, I wanted to have those freedoms when using software. It seemed that the only way I could achieve them was to write the software myself--so I set to work. Others who used my programs felt inspired to join in the effort, and we have produced a large body of useful software.
But why write a UNIX-compatible system rather than something completely new? Because this was the most reliable way to write a system that users would find usable. Writing an entire software system is a large enough task (nearing completion after eight years) even if we do not always explore uncharted territory. Today, users' demand for systems to be UNIX-compatible seems to be ever-increasing, and our Mach-based multiserver system promises to be among the most powerful and clean.
If we had chosen to add to proprietary software rather than replacing it, we could have gone "farther" in a purely technical sense. Whether this would have been better is a matter of values. I value freedom more than technical advances, so I'm happy with the choice I made. Others who value mainly material things may see the GNU project as pointless (though some do value GNU software purely for its technical quality, or because they appreciate being able to fix problems when they wish).
Duncan's disappointment with the GNU project reveals his own values. He doesn't share our values, but he should recognize the difference between succeeding at our own goals and failing at his.
Richard Stallman,
Cambridge, Massachusetts
Dear DDJ,
I was quite excited to read David Betz's article about Bob ("Your Own Tiny Object-Oriented Language," September 1991). Bob is an object-oriented language that is small enough to wrap my arms around, and I don't have to go learn weird syntax like Smalltalk.
I have Bob running on my 386 at home and on my Sparc at work. Pretty cool!
I don't really understand how strings work or what string functions are available (none except concatenation?) or how to build them. Can I index into strings like an array?
Was a console going to be added to Bob? (Good old read-eval-print!) I guess I'm looking for the ability to load Bob source files and to execute arbitrary expressions. (If load were a Bob command, it might be simpler.) A console would greatly aid in debugging Bob programs.
My eventual goal is to make Bob callable from Visual Basic. I'd rather code in Bob than Basic. To be useful, I would have to send Bob strings (expressions) to execute just like in a console.
Please let me know what your development plans are for Bob. I wouldn't want to duplicate efforts. Are there any good books on interpreters I can read?
Neil Galarneau
Malden, Massachusetts
David responds: I'm glad you've enjoyed Bob! I figured there were people who might enjoy a C-like language rather than my usual fare of Lisp-like languages.
I'll start with your first question. Strings are implemented as arrays of characters. You can use literal strings by including them in double quotes in your source file (just like in C). You can dynamically allocate strings at run time by using the newstring() function. Once you've got a string, you can index it just like a regular array. The only difference is that you can only store characters into a string, whereas you can store an object of any type in an array. You're right that the only built-in string function is concatenation, but you can write your own string functions using indexing and concatenation.
I'd love to add a Lisp-style listener window to Bob. The reason that I didn't do that right off the bat was that it isn't trivial to allow either expressions or definitions at the top level in C. It wasn't really designed to be an interactive language and requires a fair amount of lookahead to tell the difference between a function call and a function definition. My parser wasn't able to backup and retry when it failed to build a function definition from the input. I'm planning on solving this problem eventually. Also, a Visual Basic interface would be relatively easy to build once Bob has an interactive mode.
Most of the books on interpreters that I've read have been about Lisp interpreters. I'm sure you didn't miss the fact that Bob is really a Lisp-like language in disguise. I started out with an old book by John Allen called The Anatomy of Lisp and have also used Abelson and Sussman's book Structure and Interpretation of Computer Programs.
Dear DDJ,
I was interested to see Greg Renzelman's suggestion for a generic swap macro in the April 1992 "Letters" column. The problem is one of a general category of problems in which one needs to perform the same operation on different types of data. Common arithmetic operators fall into this category, but the C compiler selects the correct function or generates the correct inline code for the data type automatically.
It is a class of problems at which C++ excels. So my answer to "C Q&A" #36 is to use C++. C++ allows you to overload functions and operators explicitly. For example, the effect of the generic swap macro can be obtained in C++ by defining functions such as that in Example 1(a) for each data type.
(a)
inline swap (int a, int b) {int t; t=a;a=b;b=t;}
inline swap (float a, float b) {float t; t=a;a=b;b=t;}
(b)
define swap (a,b) ((a)^=(b), (b)^=(a),(a)^=(b))
(c)
#define Swap_(A, B) MemSwap (&A, &B, sizeof (A))
void MemSwap (void *A, void *B, unsigned Len);
Whenever you use the swap function, C++ will select the appropriate version based on the data type of the arguments. The inline specification causes C++ to generate inline code--just like a macro--rather than a function call.
It is possible, by the way, to write a semigeneric swap macro in C without using a temporary variable, as shown in Example 1(b). This works for char, int, and long values, but not for pointer or float values. Compilers tend to balk at performing the exclusive OR operation on pointers and floating-point values.
Walter Williams
Enfield, Connecticut
Dear DDJ,
Greg Renzelman's letter talks about writing a generic swap macro. The main problem I see with his approach is that a large amount of code will be generated for each macro invocation. It would be more space efficient to write a function combined with a macro to accomplish the task, as in Example 1(c), where the body of MemSwap corresponds, more or less, to the body of the macro Greg defines. If speed is at a premium (as it usually is), then the MemSwap function can be optimized or written in assembly language.
Stuart Downing
Dexter, Michigan
Dear DDJ,
In the March 1992 "Letters" column, Arpad Elo, Jr. expressed opinions about libraries, calling conventions, etc. The statements made perfect sense and reflect my beliefs as well. However, I also found some comments which I have mixed feelings about, specifically concerning Nantucket's Clipper.
First of all, Clipper is not a Nantucket database language. Clipper is actually a derivative of dBase, marketed by Ashton-Tate, which is now owned by Borland. To further complicate the issue, its syntax is similar to JPLDIS, which is reportedly the role model.
Next is the fact that Clipper produces a 160K EXE for a NULL program. This is true, but Clipper is meant to work with databases. As a consequence, it must also support indexes, relations between databases, file I/O, error handling, keyboard handling, etc. As a matter of fact, Clipper is quite possibly the easiest language in the world for coding pop ups. These pop ups can give the user vital information during the execution of an application and also give the program the capability for on-line help with a minimum of coding. I have used these features to give help at the press of the F1 key and allow changes to the help system at run time. All of that in a little over 20 lines. With this "gorilla" you get a host of valuable functions.
My third observation concerns Compile/Link speed. In every version of Clipper the culprit is the linker. How do you improve this? Replace the linker. I code heavily in C and assembly and as such, I own several Borland products. In these packages comes a great little linker, TLINK 1.0. It may be slightly limited (it can't generate overlays), but it is only 10K and can link faster than any other linker I have tried. Next on the list is the linker that comes with Borland C++. This linker is also fast and is extremely capable. If you don't have these, Microsoft's linker and also BLINKER claim fast linking.
With TLINK 1.0, Clipper Summer '87 can compile/link tons of source and custom libraries and produce a full app in 18 seconds on a 16-MHz 386SX.
You could also enhance linking by using caching programs or creating a huge RAM disk and putting your libraries on it. There's more than one way to make Clipper fast.
Also I have heard that Hello World can be reduced to approximately 5K with Clipper 5.0, using its runtime capabilities.
The point of this letter is this: Pick the right language for the job. Don't use Clipper to do non-database jobs, and don't think about writing a database app in C or assembly language. It can be done, but the time it would take to code a multiuser, multiple-database application with record- and file-locking features, online help and the myriad of other features it would need, would be unbearable.
I believe the best programmer is the one who knows several languages, realizes their benefits and drawbacks, and has the sense to code using the optimum language. If there isn't one, then roll your own. Isn't that what America's about?
John McKnight
Bad Axe, Michigan
Dear DDJ,
Congratulations on a consistently superb publication. Dr. Dobb's Journal continues to set a mark all computer-related magazines would do well to emulate.
I can only echo the sentiments in Jonathan Erickson's excellent February 1992 Editorial on the RBOC/BBS confrontation. As he implied, the issues may be wider than just bulletin boards. Essentially, the local telephone companies are desperately seeking to maximize their take from any use of telephone service beyond a voice call to Aunt Rose. Effective data use of the wires by the mass of computer users is being held hostage--to the detriment of our society and economy. The stand-off between RBOC and BBSs is simply the most visible and current confrontation.
Jack Rickard Editor, Boardwatch Magazine
Lakewood, Colorado
Copyright © 1992, Dr. Dobb's Journal