If This Is June, It Must Be Zurich

As with our stateside sojourns in the Dobbsmobile, our international travels involve many technical hardships. This time, I found myself up the creek, er, across the ocean without a C++ compiler. The laptop had just come back from the repair shop sporting a new hard drive and needing to be retrofitted with my working software and data. I got as much installed as I could before leaving home and brought the rest on CDs — including a DVD with beta 2 of VisualStudio.NET and the .NET Framework. I'm using the new environment at home on an XP Professional desktop for C++ programming and to learn C#. But after I got here, the setup program hung up when I tried to install the software on my XP Home Edition laptop. They've probably addressed this problem since beta 2, but I do not have a newer version. This one came shrink-wrapped with a special issue of DDJ sometime last year and I've been happily using it ever since. Microsoft finally caved in to the Standard C++ specification. The new version of Visual C++ has the things in the std namespace that ought to be there and the environment is much closer to supporting Standard C++ development than any of its predecessors.

A month without a C++ compiler does not make for a contented traveler. I hotfooted it down to the local Internet Cafi. Reinforced with a three dollar gulp of local coffee (which you could patch a driveway with), I logged on to my web site (http://www.alstevens.com/quincy2000/) and downloaded the Quincy 2000 IDE and the mingw32 port of the gcc compiler suite from ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2/.

Thus equipped, I can sit on a park bench with the laptop in my lap and look across Lake Zurich where lazy swans and sailboats while away the day. The majestic Alps rise in the distance to the south. There is a picture postcard scene of the old city everywhere I turn. Lunch is a hard roll, a wedge of cheese, and a paper cup of red wine. Earphones block the city noise, letting in the jazz MP3s from my hard drive. And I can hammer away at the C++ algorithm du jour (der tage?). It doesn't get any better than this.

I am, however, still without a C# development environment until I return home in July. For that, I can wait. Judy said, "You think you've got it tough? The home shopping channel here is in German."

The Mailbag

The mailbag runneth over. Many readers responded to my June column about how I encoded six discreet logical audio channels into one stereo .WAV file. Several of you pointed out that my solution is what is called "time division multiplexing" in other disciplines. So it is. Now I know what to call it. I am still unaware of that technology being used in this kind of application.

Some readers were concerned about the loss of fidelity in the 14.7-KHz sampling rate of the remixed signal. One reader suggested that I might not be able to discern the loss, but my children would. Thanks a lot. The audio loss in this particular application is not a problem. First, it's not all that discernible because the musical ensemble is a roaring Dixieland band. Second, it's not all that important because the product is a teaching device and not aimed at audiophile purists. Third, even at that reduced bandwidth, the playback quality is far superior to the original recordings of that particular genre of music. 78 RPM records from the 1920s and '30s are prized for their historical and collectible value, but certainly not for the accuracy of their sound reproduction.

Two readers, Michael Zarky and Russell Borogove, submitted an improved way to upsample the mixed signals to 44.1 KHz for sound cards that do not support the lower bandwidth. They were right. My way, which duplicates samples in triplicate, produced unacceptable sound. In the technique they suggest, samples are interpolated and the resulting sound is more acceptable.

In my July column, I discussed C#'s interface feature and the absence of multiple inheritance for classes. In my view, being forced to use only single inheritance violates the IS-A, HAS-A, USES-A principles of object-oriented design. I drew an analogy between multiple inheritance and the old outhouse at the farm, describing what I call the "outhouse paradigm" in that column. The mail is starting to come in on that issue and I'll discuss it further after I hear from more of you. But one reader, Kent Anderson, hit the nail squarely on the head with this observation:

Having Java inflicted upon me for a few years, I've grown accustomed to using the HAS/USES relationship rather than IS-A, as you described. I've often visualized it as turning the IS-A on its side (based on the convention of drawing base classes above, and used classes on the side of the class that uses them). Of course, you can imagine the mess when you turn an outhouse on its side!

Imagine, indeed. It calls to mind many a Halloween of my youth.

More DSP

I have other digital signal processing projects in the works. If such things interest you, take a look at Intel's Signal Processing Library 4.5 (http://developer.intel.com/software/products/perflib/spl/). The library is distributed as DLLs and programmer documentation for audio, video, and communications processing with APIs for C++, Visual Basic, and Delphi. It includes functions for finite and infinite impulse response filters, Fast Fourier Transforms, wavelet transforms, tone generation, and vector operations. These functions just might save you a lot of work. The license is liberal with respect to how you may use and redistribute the library. I haven't tested the FFT to see how it works for real-time processing, which is one of my requirements, but this library is a good starting point for experiments with digital signal processing.

The Over-The-Hill Gang of Four

The August issue of DDJ had many articles about methods and methodologies for improving programmer productivity. You know what? I've been reading about the problems of programmer productivity and various would-be solutions to those problems for about 40 years now. We've added programming languages, developed new design and coding models, and administered various logging, charting, and reporting conventions in many futile attempts to ensure that programming teams build working software systems that support users every time, on time, and within budget. But the problem persists because we keep trying to solve it. I think it's time to forget all the procedures and consider what ought to be an obvious solution.

I started thinking about this problem and a solution years ago when I bought a house in a suburb of Washington, DC. The house had brick walls. When it was completed, I was struck by an odd visual effect in the brickwork. All the houses in the development exhibited the same effect. The brickwork from the foundation to about eye level was high craftsmanship with perfectly laid bricks and perfectly sculpted mortar. From there up to the top of the second floor, the brick work was imperfect with unevenly placed bricks, badly matched bricks, and roughly slabbed mortar. I went to a part of the development that was still under construction, watched them work, and saw why. The master brick masons didn't climb ladders. They worked at ground level, leaving the higher work to the apprentice brick masons. There were two reasons for this: First, the masters, being older and having seniority, didn't care to and didn't have to climb ladders and balance on scaffolds; and second, the upper work involved more bricks, thus more apprentices drawing less pay, thus a cheaper labor cost.

My hypothesis was reinforced years later when I played piano in a big swing band made up of young players who had enthusiasm for that kind of music but not much experience playing it. At the same time, I was a substitute pianist for a different big band of volunteers comprised mostly of retired musicians from the big band era. There are plenty of those old guys in Florida. The young guys can hit higher notes and last longer but the old guys have an edge in their playing that you can hear but cannot describe. They are just better big band musicians.

What the master brick masons and old-timer musicians have in common is experience. The longer you are in the tooth, the better you are at what you do. Maybe the senior citizen can't climb as high on a ladder or a treble clef, but within the normal range of human activity, the older worker has no equal. Or so it would seem.

With that in mind, I concluded that the problem of insufficient programmer productivity can be solved with a simple approach. Hire old programmers.

I thought back to some programmers I met in my early days in the business, those mentors and teachers, programmers with whom I apprenticed and from whom I learned my trade. I thought about three programmers in particular who had one thing in common — they all began programming in the early 1950s, about the same time that programming, as we know it as a profession, got rolling. I figured if I could find those three programmers and drag them out of retirement, I would have the most experienced programming staff possible, a programming dream team.

I found all three. To respect their privacy, I'll address them with the names we called them in their prime: Annie, Koby, and Sharkey. I knew them at my first programming job. All are now retired and living in Florida. They agreed to meet with me for an exploratory session to see if we couldn't recruit more retired programmers, pool all that experience, tackle some meaty development projects, show the kids how it's done, and prove my hypothesis.

We met in the day room of the Sunshine Nursing Home where Koby lives. He didn't care to travel, and the others didn't mind. I was the last to arrive. Annie was sitting in a wicker rocking chair working on some needlepoint. Sharkey stood near a window examining the window itself rather than looking out at the peaceful surroundings. Koby sat in a straight-back chair with a white-jacketed orderly standing behind him. Every now and then Koby would lean off to one side or the other as if he was about to fall off the chair. The orderly would grab him by the shoulder and sit him upright.

Here's how it went:

Al: Welcome to the Project Yesterday Software Team. I assume you all remember one another from the old days. My letter explained our reason for getting together. I thought we'd begin by...

Sharkey: The Project Yesterday Software Team? PYST? I can't wait to get the T-Shirt.

Al: Well, maybe first thing on the agenda would be to choose a better name.

Annie: NOPT, let's call it NOPT.

Al: What's that, Annie, an op code from an old computer?

Annie: Nit one, Perl two. Get it?

Annie cackled into her sewing basket. Sharkey fiddled with the windowsill trying to open the window. Koby leaned off to the right. The orderly grabbed his right shoulder and sat him upright.

Al: We'll talk about a name later. First, I think we ought to document our credentials with a press release that emphasizes the depth of our knowledge and experience. We have almost 200 years combined experience spanning half a decade. Who could be better qualified? We've all seen major advancements in our industry in that time. What, to each of you, is the most important development in programming, the one thing above all other things that made programming easier and more productive? Was it the high-level language? Structured programming? Object-oriented programming? The Internet? Design patterns?

Annie: The stored program concept. Things got a lot better after that. That Von Neumann kid had a head on his shoulders. A nice young man. Whatever became of him? I bet he got a good job.

Sharkey: I'll never forget my first run sheet. That changed my life. Finally got the respect a programmer deserves not having to operate the computer myself. Just fill out that run sheet and let some lowly operator do it. Run sheet in, core dump out. Now that's programming.

Al: Well, I was kind of thinking of things more current than that. What about you, Koby? What do you think is the most important productivity aid in your later years as a programmer?

Koby leaned off to the left. The orderly sat him straight again.

Koby: That's easy. Kaopectate. Or was it Metamucil? I forget. Whatever, it sure kept us at our desks more.

Al: Well, okay, those are all good inputs. Let's try a different tack. What do you think is the most important advance in hardware since you first started programming?

Annie: Core memory. It sure was a pain changing those vacuum tubes all the time. Burned your fingers. The keypunch was good, too, but I forget what we used before that.

Sharkey: I think the most important advance was the window.

Al: You mean Windows? The OS?

Sharkey: No, the window. The one we used to submit jobs. Anybody remember the window? You shoved your run sheet and card deck through the window. After they developed the window, programmers never had to operate the computer or conduct our own tests again. Some guy on the other side of the window did it. I sure missed the window when they did away with it.

Koby leaned to one side again. The orderly promptly corrected him.

Koby: Those were nothing. The most impressive invention was the thermos bottle.

Everyone: The thermos bottle?

Koby: Sure. You know. You put something hot in it, it keeps it hot. You put something cold in it, it keeps it cold. How does it know?

Al: Let's talk about something less technical and more controversial. What do you think is the best solution for the Microsoft problem?

Annie: That young Bill Gates needs a good talking to. I bet he'd listen to me. If not, I'd box his ears, the whippersnapper.

Sharkey: Just wait a couple years. Those little PCs are a flash in the pan with all their gooeys and mice. Before long, we'll be back to submitting our jobs with run sheets through the window the way it was meant to be. What do these kids today know, anyway? They don't even wear ties.

Al: Koby, what do you think will solve the Microsoft problem?

Koby leaned to the left and the orderly set him straight.

Koby: Viagra. Take one of those little hummers and wait a few minutes. No more micro soft problem.

Al: Well, I guess we're not getting anywhere today. Maybe everyone is a little tired. Let's call it a day and agree on a date and time for our next get together.

Koby leaned to the right and the orderly once again sat him up by the shoulder.

Koby: Could we have it someplace else? I don't like this place.

Al: What's wrong with it.

Koby leaned to the side again and the orderly straightened him up.

Koby: They won't let you fa...

Everyone: Koby!

DDJ