Mr. Ward:I feel obligated to respond to Mr. Curren's letter (CUJ, December 1990) criticizing you for including the SoftC Database Library in Volume 326 of the CUG library.
Mr. Curren was upset because he believed that our licenese agreement demanded a royalty payment for each copy of his application he sold. This is simply not the case! We try to make this clear in the "Product Code and Derivative Works" section of the license agreement with the following statement:
"The Customer may reproduce and distribute application programs created using the Product without additional licenses or fees."
I think this plainly states our position that we do not expect any royalties from our users. We do restrict the ways in which the library alone (not as part of a derivative product) can be used. Essentially we say that the library is to be used like a book. Perhaps Mr. Curren made the mistake of also extending this restriction to his applications.
We think our support policies clearly reflect our user-orientation. Fixes for all reported bugs are available directly from us at no charge. Prior to each release our library is subjected to several thousand tests (1 megabyte of source consisting of 195 test files). We do our best to ship bug-free software.
It's unfortunate that Mr. Curren let the licensing issue keep him from "test driving" our product. The combination of our product with the CXL library (Vol. 278) has proven to be extremely powerful and in many ways more flexible than our competitors'. Many of our users have returned competing products after trying our library.
It is indeed unfortunate that Mr. Curren never sought to contact us. We would have been (and still would be) happy to provide explanations for any questions he may have had and even supply a free shareware version of the library (as we have done for many other software professonals who have called with questions).
Finally, I am curious why you printed Mr. Curren's letter without a single comment. It seems out of character for you to allow such complaints to go without response. Are you aware that your silence gave the impression that you concurred with his statements?
Sincerely,
Kim Schumann
Chief Software Engineer
SoftC, Ltd.
16820 Third Street N.E.
Ham Lake, MN 55304-4703Thank you for clarifying the royalty issue. As for not answering the letter, I sincerely hope everyone knows that letters from readers represent only their authors' opinions, not mine nor the magazine's. We publish all kinds of letters we don't agree with; that's part of being a forum. Many factors influence whether a specific letter gets answered: whether we have room for the answer, whether I know anything about the subject, whether I think it deserves legitimization, whether the muse is sitting with me.
We certainly didn't mean to endorse Curren's opinions by not responding. I apologize if the letter gave that impression. Thanks for the support. — rlw
Attn: Rex Jaeschke
Dear Sir:
I enjoyed your article in the Sept '90 issue concerning use of the qsort function. Under the subheading Multikey Sorts, however, you make the recommendation (as I understand it) to separately sort the primary key and then make smaller subsorts of each secondary key. Under any circumstances that I have been able to imagine, this should not be necessary as long as the sort function passed makes its determinations giving the primary key full priority over the secondary, that is the secondary field is only used if a complete match occurs in the primary. This has always worked in any place I have used it.
Sincerely,
Jay Holovacs
95 King George Rd.
Warren, NJ 07059-6921I agree. Thanks. — Rex
Dear Mr. Plauger,
Here are a couple more solutions to Dale Wharton's problem. They should work regardless of the host character set. The first (printc) puts out a format suitable for re-encoding with sprintf (when using the same character set). The second (printasciic) decodes ASCII. Both are shown in Listing 1.
Your magazine has been one of the most useful I have ever subscribed to. I keep digging into my stack of past issues looking for things I remember are there somewhere. Do you have any plans for indexing past issues? I've also enjoyed your work since Software Tools. My copy of Standard C is already looking pretty beat up. It's good to see you step in as editor of the jounal.
Sincerely,
Eric Blossom
2737 Russell Street
Berkeley, CAThose are both useful functions. I can't count how many times I have cobbled versions with only part of the needed functionality. Thanks for passing them on. And thanks for the kind words. — pjp
And yes, we are planning a comprehensive index... soon? — rlw
Editor:
I often use the following code when it makes more sense than a do-while loop:
#define until (expression) \ while (! (expression)) do {..... } until (something happens);A typical use would be to read the keyboard and stay in the loop "until the key pushed == ESC." It's just easier to think of than to stay in the loop "while the key ! = ESC". Or for infinite loops:
#define HELL_FREEZES_OVER 0 do {..... } until (HELL_FREEZES_OVER);Sincerely,Donald Gessling
Dynatech Nevada
2000 Arrowhead Dr.
Carson City, NV 89706If you feel that helps readability, fine. Just be careful when you ship code to other folks - they may not agree with your notions of a good language. I have seen C altered, via macros, to read like Pascal PL/I, and Algol 68. That can certainly please recent converts, but it can interfere with maintenance if you go overboard. — pjp
Dear Mr. Ward,
I have just received your final notice of my subscription expiring, and am taking the time to inform you as to why I'm letting it go.
First, let me point out the admirable aspects of your magazine; it deals wholly in the C family of languages, your Q&A section is unique in its ability to answer questions without belittling the asker, there's a good mix of narrow band and wide band articles with respect to their intended audience, and the regular authors generally cover important topics for the professional programmer. Taken as a whole, these qualities represent a formidable arsenal for the subscriber/regular reader.
Unfortunately, there is one severe drawback in your implementation of The C Users Journal: source code. It simply is that important. Let me illustrate through example. Suppose you buy a paper which describes a fantastic squash casserole. You say to yourself, "Gee, I really like squash, how do I make this?" Upon close examination of the paper, you find that it will cost you two to four times as much for the recipe as it did to hear the description! You may be miffed the first time, but after twelve issues of the paper, each time seeing something that would be nice to make (without violating any copyrights, of course), and each time being reminded that you'll have to pay again for something that should have been in there to begin with, you get to the point of disgust. This is why I am no longer interested in maintaining my subscription with CUJ.
Since I have defined a problem, it is only proper that I try to define a solution. There are two options that I can think of, though I'm sure I haven't exhausted them all. First, what of an online listings service (BBS)? Doctor Dobb's Journal uses one with great success. They archive the listings and name them with the three letter month mnemonic and the year of the issue (ie, aug90.arc). the users could then retrieve any listing they desired at their convenience. Second, printing the listings in the magazine itself would solve this dilemma, but would increase the number of pages in the magazine. Paper is everywhere, subscribers are not. Right now, the cover price is $4.50 and the subscription price is $2.25. This comes to approximately 3.1 and 1.6 cents a page, respectively. Is your overhead that high?
Each possible solution described above assumes that you do not wish to make a profit from your followers twice for one thing: solutions. Since I tire of being teased, I shall wait patiently until you deem it fitting to freely allow access to the source listings (those that are allowed access by the copyrighters' consent). At this time, I shall enthusiastically resubscribe. I have a lifetime to wait, can CUJ afford that luxury?
Regretfully,
Steve Vickers
Apopka, FL 32712I too am regretful. You write a very rational letter, arguing a position with which I totally agree. But I don't understand — why do you perceive us as withholding source code?
You say one solution is to print the listings in the magazine. That's exactly what we do! Apparently we've inadequately communicated something, please help me figure out what.
In all but a few rare exceptions (where the listings would run hundreds of pages), we print full source code with each article. We also offer this same source code on disk for a $5.00 service fee. Perhaps we haven't explained the code disk well enough? Occassionally we put extra goodies on that disk (like maybe a shareware library that was mentioned in a story), but aside from such bonuses, the code disk is just a machine readable copy of the source that appeared in the magazine. We're certainly not trying to force you to buy the code disk by holding back essential source!
Are you referring to the code on CUG volumes? We report on what's available in the CUG library, just as we report on developments on Usenet and other PDS sources — surely you don't expect us to print all that source just because we mentioned it? We're talking about multi megabytes of source here!
As for putting the source on a bulletin board, right now I don't think we have the staff to properly administer such a service (keeping the overhead low and all that). We hope to remedy that in the next few months, either by adding staff or making an arrangement with a reputable volunteer site. But nevertheless, since printing the source is an acceptable alternative for you, I don't understand why you think we've failed. — rlw
Dear Dr. Plauger:
I have another interpretation of the question from Mr. Wharton (November 1990, We Have Mail). If he is using an IBM-PC style computer, control characters have been assigned various symbols such as card suits, arrows, and smiley faces. The catch in displaying these characters "the way printed charts picture them" is not with C, but with DOS and BIOS. When characters such as bell and line feed are sent from the C environment to DOS (via printf(), putchar(), etc.) they are executed with their traditional meanings, which is what most of us want most of the time.
In order to display the special PC symbols with the same codes, it is necessary to bypass DOS and call the BIOS directly. (See Listing 2. ) Books on PC graphics or PC hardware that explain other interesting BIOS functions should be available at any computer bookstore.
Sincerely,
Bob Raemer
8960 Neill Lake Rd.
Eden Prarie, MN 55347Thanks to you, too — pjp
Dear Mr. Ward:
In the October issue, Andrew Hollands mentioned Modula-2, and you expressed interest in hearing from readers who use it extensively. I have been programming professionally for many years and have used many languages. Excluding the research and experimental languages which are not generally used or available, Modula-2 is my clear favorite.
When Wirth first published the description of Modula-2 around 1982, I was a bit disappointed in it. Since then, a few of the original problems have been fixed, and my point of view has changed in light of the alternatives. There are still a couple of things about Modula-2 that I wish were different, but overall, I find it a great productivity enhancer.
The best summary I can give is that Modula-2 has the necessary trapdoors so that you can do low-level (and probably machine-dependent) stuff when you really need to, but it provides a lot of safety most of the time, when you don't. You won't fall into a trapdoor inadvertently.
By contrast, C forces you to use too low-level constructs in several extremely common situations where they aren't needed, because there is nothing else. My favorite examples are explicit use of pointers when arrays and by-reference parameters are really needed, and the fact that every pointer is really a pointer to one element of an infinite array, whereas a pointer to a single object or into a bounded array is usually what is really needed.
Modula-2 also has a type-safe separate compilation facility, and a method of packaging data structure with the procedures that operate on it. While these features have been regarded as standard techniques for many years by programming language researchers, Modula-2 and Ada are the only languages with any degree of popularity which fully support them. (Some of the object-oriented languages finally emerging do provide an improved variation of the latter feature.)
I have also used Ada professionally for about five years now, and I continue to be more and more disillusioned with it. It has a lot of useful features, including a few which Modula-2 lacks. However, it also has a mind-numbing array of complex and bizarre rules that depend on every imaginable factor short of the phase of the moon. A colleague recently remarked that even after five years programming in Ada, he still frequently encounters a simple declaration or statement whose real meaning he can't be confident he understands, without spending hours poring over the reference manual.
A lot of the desirable features of Modula-2 which distinguish it from original (and ISO) Pascal have also made their way into the various implementations of Pascal too. Pascal compiler implementors have apparently recognized these as valuable, and put them in as compiler-specific extensions to the language. However, since Modula-2 got these in the (original or revised) language description, they are more portable than in the dialects of Pascal. Also, no Pascal that I know of has separate interface and implementation modules. The popular UCSD Pascal units support type safe separate compilation, but they force massive recompilation, if you have to touch one.
A standardization effort for Modula-2 is well underway. To some extent, it too suffers from some of the usual problems stemming from trying to solve tough technical dilemmas while immersed in political battles. However, the process has begun much earlier in the history of the language than usual. There is not nearly so great a proliferation of dialects as there were of Pascal and C, when standardization of those languages began. Hopefully, this will lead to a standard which is not so far out of sync with established practice, and which will be better accepted.
"Standard" Modula-2 does, of course, lack object-oriented features. Despite all the excessive hype, object-orientation has tremendous value for programming. There is an object-oriented dialect of Modula-2 from JPI. This is even better than plain Modula-2, unless you care about portability, as I do. In that case, you can hardly afford to use the object-oriented features, since they are unique to one machine, one operating system, and one compiler. (Perhaps some day, I will write a letter about Modula-3, which, though little known, is considerably more powerful than Modula-2, is almost as simple, and has object-oriented features in its original report.)
Mr. Hollands refers to Modula-2 as a "crutch," and you state that debugging in C (but presumably not in Modula-2) is too difficult for students. I have heard from countless people who believe that, for an experienced programmer who has the ability to cope with a more difficult language like C or Ada, an easier-to-use language like Modula-2 has no real advantage. I disagree. I can cope with the difficult languages as well as anybody, but I also care about my own productivity. I prefer to devote as much of my programming skill as possible to solving real problems which could not be solved for me mechanically by a compiler for a programming language which uses well-known language technology.
Modula-2 has been slowly growing in popularity for a long time. We have all heard the argument over and over, that the technical quality of a programming language has little to do with its actual success. What will actually happen to Modula-2 remains to be seen, but I think it looks more likely than ever that it will be successful. It already enjoys far greater popularity in Europe than in the United States. Even here, it is already sufficiently successful that there is little doubt that a compiler will be available for most any machine/operating system you decide later to port your code to. In the meantime, I am having more fun than I've had with any programming language in 25 years and getting more code working in less of my time.
Rodney M. Bates
1513 Blue Spruce
Derby, KS 67037Thanks for a very thoughtfully-written letter. — rlw
I agree that Modula-2 is a definite improvement over Pascal. I also agree that a programming language should do as much of the dirty work as possible. It should minimize the number of error-prone operations you have to perform.
My observation, however, is that Modula-2 is not spreading like wildfire. It is true that the language is more popular in Europe than in the U.S. So, too, were Algol 60, Algol 68, and Pascal — none of which have survived as serious commercial programming languages. If you gamble on widely available compilers and support tools soon, you're taking a serious risk.
What makes a language a rip-roaring success is not always easy to quantify or articulate. Many find C, and FORTRAN before it, inelegant or outright dangerous. Others simply notice that you can get a lot of work done by programming in C. I'm just grateful that the Elegance Police don't have much power. I prefer the freedom of an open marketplace.
If the marketplace makes Modula-2 a winner in the next few years, I'll have no objections. Someday, we may even see a Modula-2 Users Journal. For now, I just view languages like this as interesting experiments.
But then, I'm notoriously pragmatic. — pjp
Dear Robert Ward,
I am a developer who is working with C for the Windows platform. I am looking to purchase a library of statistical routines, the most important of which is Multiple Regression (linear fitting).
My first choice for the library is one that is written for the Windows environment. However, if such a thing does not exist I will settle for a library for which source code is available. The source code will have to be written in C.
Any help that you can give me in this area is immensely appreciated. Thank your for your kind attention.
Avi Farah
Price Waterhouse
65 Madison Avenue
Morristown, NJ 07960-1940Both CUG 266 microPLOX and CUG334 GNUPLOT are not statistics packages, but would provide an excellent tool to help your statistical analysis. Both packages take commands and data input and display or draw graphs/charts on monitors or printers. microPLOX would be appropriate for drawing a bar chart, while GNUPLOT is capable of drawing graphs or plotting data points based on a given mathematical function (built-in or user-defined), such as sin(x), cos(x), etc. GNUPLOT supports an extensive set of graphics drivers including PostScript.
With these tools, all you need may be some mathematical formula to implement statistical techniques. However, CUG library still lacks an integrated statistical package, for which we count on submissions from readers. — Kenji Hino
Dear Mr. Plauger,
I received your special introductory offer in the mail today to subscribe to The C Users Journal. I don't usually write to people who send me offers to subscribe to a magazine; this is the first time, but I have a suggestion for you which may help increase the number of subscribers that you have.
I subscribed to your magazine a while back, as I was attempting to learn C. I had purchased Borland's Turbo C, along with a couple of books on C. I was struggling to learn the language; it was unlike Basic or dBase, which I had taught myself by reading the manuals and trying different things out. The C language is very powerful and unique!
I found your magazine to be more in depth than what I was ready for at that time. The reason I'm writing to you now is I think there is a market for a publication that addresses itself to the beginning and intermediate market. There are a lot of people out there like me who bought and continue to buy Turbo C or Quick C because they want to learn the language, but the complexities and new concepts like pointers are just overwhelming at first. Why don't you tap into that market?
You could create a separate magazine that holds the hand of the beginner and teaches him basic things, and which also has sections of interest to the intermediate C programmer. As the person became more advanced, he could move up to The C Users Journal. Alternately, you could just expand The C Users Journal to cover topics of interest to all, from beginner to expert, but that would be more intimidating to the new user, as well as a partial waste for the advanced user. By having two separate publications, you're not sending out a lot of pages that a subscriber has no intention of reading.
You have a wonderflibrary, and you have the resources to do it. You definitely have the technical expertise to do it, and there's no magazine on the market at this time that I'm aware of that caters to beginning C programmers. The market's all yours!
If you should decide to expand and go for the beginning market, let me know and I'll be more than happy to subscribe, and I'm sure a lot of other people will too. You could even include a flyer in packages of Turbo C and Quick C to let new buyers know of your publication(s).
Thank you for taking the time to consider my proposal, and I look forward to hearing from you soon. I wish you the best of luck in your publishing endeavors!
Sincerely,
Vincent Harris
P.O. Box 1324
Sebastopol, CA 95473A magazine can't be all things to all people. We do try to publish a range of editorial material, some for beginners and some for advanced C programmers. Keeping both a broad range and a tight editorial focus is a continual balancing act. We can only keep trying to get it right.
Starting a new magazine is a publisher's decision. That's Robert Ward's domain. I just edit here. — pjp
Dear CUJ:
In your November, 1990 article "A Flexible Dynamic Array Allocator" by Dick Hogaboom, I located a small typo that keeps the routine from correctly initializing arrays. On page 118,
p_data = base + data_off * ptr_sizeshould be
p_data = base + off(num_dim-1) * ptr_sizeRegards,Jon Michaels
61 Cutler Road
Greenwich, CT 06831Thanks — pjp