Letters

Terry Collins

terryc@woa.com.au

Dear DDJ,

Jonathan Erickson's February 2000 editorial is spot on and the circumstances described in "Worker Shortage a Tall Tale?" are identical here in South Africa, although the numbers are naturally considerably less. My point is that I believe it is a global problem.

Geoff Davis

davisg@cybertrade.co.za

Dear DDJ,

Regarding Jonathan Erickson's February 2000 editorial "Worker Shortage: a Tall Tale?": I think the major problem is a sort of mathematical dysfunction among the powers that be. They seem unable to calculate the real cost of a hiring or retraining a person. They do their math with the simple up-front numbers.

They seem unable to work out savings that can be attributed to experience and forget the time it takes to train people so that they become productive. In the real world, with systems like SAP, Oracle financials, and IFS may take from six months to more than a year. During that time, these people reduce the productivity of their fellow workers. As far as I know, there is nothing that can replace experience when you are dealing with hundreds and thousands of users.

I believe that some e-business sites have been bitten by this problem. Their software is not good enough because they have hired programmers who have web- related skills instead of those who know how to create the type of applications they use. This skill takes time to learn.

I suspect a lot of managerial types have completely unrealistic notions about how long it takes for a programmer to come up to speed with new stuff like the Web or a new programming language like Java. As a matter of fact, many programmers share that problem. I suspect they believe that it will take years (while the reality is that it takes less than a month) to change language. And many forget how long it takes to do things in general. There is usually plenty of time to retrain or learn new skills.

There might also be a lack of knowledge of how to leverage existing skills to produce quality Internet software. Why use Perl if your staff can do the same job with Cobol or pl/sql in the same time and with a lot less security concerns?

Tarjei Tjxstheim Jensen

tarjei@online.no

Music City

Dear DDJ,

I just wanted to say that the January 2000 issue is one of the best issues of DDJ I've ever read. One thing troubled me, though: The article "The Ultimate Home Jukebox," by Mark Nelson and Charles Mungo failed to mention that the activities in the article were illegal. By not printing a disclaimer, the RIAAA (Recording Industry Association of America (http://www.riaa .org/) might consider the article an encouragement of copyright infringement. According to recent RIAA [rules], making a digital copy of copyrighted music is only legal with minidiscs. The reason that doing so on a computer is illegal is because second-generation copies of the copies retain their quality, thereby supplying the ability to bootleg.

Raj Dash

rdash@diginc.com

DDJ responds: Thanks for your note and I'm glad you liked the issue. Yes, what the article describes would be illegal if the system were installed on, say, an Internet web server or a LAN server. However, for personal use on, say, home networks, the system the authors describe is entirely legal. The RIAAA may say it is illegal, but that doesn't make it so. The article is clearly aimed at personal use (note the title "...Home Jukebox"). Copyright law lets you make copies of software, videos, audio, and so on, for personal use -- assuming you legally purchased the original copy in the first place.

Sorting Through Sorts

Dear DDJ,

Thanks for publishing the March 2000 "Algorithm Alley" article by Mingfu Gong on group sorting algorithms. Sorting is a rich lode of learning available to all programmers. Gong's algorithm is a modified Comb Sort (see Lacey 1991, plus many web sites). Gong did make reference to Shell's 1959 paper, although it used Insertion rather than Bubble techniques, and sorted each group to completion, unlike Gong or Lacey.

Also, the innermost loop in the Gong method uses a bidirectional bubble sort. This violates his own principle of regrouping, because many of the same pairs will be compared twice. Using an alternating-direction bubble sort is likely to be better. The cmprSwap2 routine is an unnecessary complication. It is logically equivalent to a pass through bubble with numGroup=N/2. If its speed is different, this needs to be explained.

The shrink factor, as defined by Lacey et al., is the reciprocal of the GNDR as defined by Gong. The tests shown were GNDR=2/3, 3/5, 4/7, and 5/9, corresponding to SF=1.5, 1.67, 1.75, and 1.8. There is no reason to believe that the best answer does not lie between these numbers. Lacey's method is optimal for values from SF=1.45 to SF=1.30, depending on implementation details. Gong should at least test with 10/13. It is possible that the redundancies inherent in the bidirectional bubble technique force Gong's numbers to be different from Lacey's, but that is not clear from the data presented.

The Gong algorithm is not adaptive in any meaningful sense. If the number of swaps made in each call to the bidirectional bubble sort were counted, and used to determine future values of GNDR, we would expect it to be called "adaptive." Changing the title from "An N*logN Adaptive Group Sort Algorithm" to "An N*logN Comb Sort Algorithm" would help considerably.

Despite all these weaknesses in implementation, the approach is so good that the results are often superior to Quicksort for random lists, and are doubtless even more superior for real-world lists. There is little doubt that a carefully optimized Comb Sort will soon be published [that is] demonstrably better than Quicksort for a wide range of input data types, simpler to write, and not using recursion. I hope DDJ will continue to play an active role "coaching" the programming profession through the "labor pains" necessary to give birth to this "baby."

Rick Box

rick.box@scalablesoftware.com

Buy The Book

Dear DDJ,

My buying instincts are somewhat at odds with Larry Sollman's ("Letters," DDJ, March 2000). First, I categorize subjects into "soft" ones and "hard" ones (extreme example: X protocol programming is hard, HTML authoring is soft). That tells nothing about the inherent difficulty of the subject; it merely reflects the established hopes of the public about which subjects one can master without getting involved too uncomfortably close with "computerese." Needless to say, reality sometimes contradicts this established wisdom. But it's nevertheless a useful distinction to make, because it's a distinction I've found the publishers themselves make when deciding on the "level" of the book. So, we come to:

Advice #1: When buying books on a "soft" subject, look first for ones marked "Advanced," "Guru," or "2 Ph.D.s required." It's the only way to avoid hundreds of worthless pages explaining a handful of concepts over and over again. Publishers seem to think that concise and to-the-point writing is understood only by people with great skill and IQ.

Advice #2: Fat books on "soft" subjects are suspect. They're probably filled with screen shots and code snippets that manage to fill a whole page with 10 [lines of code] using extra-large intraline spaces and huge surrounding boxes.

I'll risk another advice:

Advice #3: Avoid any book "*for Dummies", "Learn* in *days," "*bible," "*unleashed." Real experts write books in series whose names are not included in the titles of the books (examples: International Computer Science Series, World Wide Web/Programming Languages, and so on.)

Here's another one:

Advice #4: Go directly to the source. Looking for a good first book on C++? Read Stroustrup's book, then move on to others for more, if you like.

The essence of this advice is: Don't avoid learning to drive a car because you think learning to ride a bicycle is faster and easier. It might be, but using the car is faster and easier.

I hope this other view on the subject will complement Sollman's.

Dimitrios Souflis

dsouflis@ovrimos.com

E-Address Change

Dear DDJ,

I was pleased that my article "Measuring Network Software Performance" was included in the March, 2000 issue of DDJ. One note, my e-mail address has changed. If any readers have questions, I can be reached at jyun@ieee.org. Secondly, I ran across a typo that might confuse some readers. In the second to last paragraph on page 88, the phrase "degree if certainty" should be "degree of certainty."

James K. Yun

jyun@ieee.org.

Open Source Debate

Dear DDJ,

I was surprised and somewhat dismayed at the sentiments expressed within the December 1999 letter "Open Source in Turkey." Your correspondent's position appears to be "give it to us free, or we'll take it anyway". Given that a significant proportion of DDJ's readership earns its living through the development of commercial software, I do not believe it is appropriate for you to publish advocates of software piracy.

Guy Hammond

DDJ responds: Guy, thanks for your note, but just because we published the letter you refer to doesn't mean we advocate software piracy. Quite the contrary. We published the letter for a couple of reasons, among them as a reminder that the open source movement is world wide, and that there's a downside to some people's understanding of open source.

DDJ