Channels ▼
RSS

C++ Users Journal: 20 Years and Counting


November 2001/C/C++ Users Journal: 20 Years and Counting


With this issue, C/C++ Users Journal celebrates its 20th anniversary. The actual birth date may be debatable (see “A Brief History” below), but the magazine is well past gawky adolescence. Given its specific focus, the fact that CUJ has remained relevant for so long is owing to the vitality of the language(s) it covers, but even more to the community of developers who share their experiences. This celebration, then, is a celebration of that community: long may it live.

A Brief History

June 15, 1981 — The first issue was published as a 16-page quarterly newsletter entitled BDS C Users’ Group. Robert Ward was the volunteer group coordinator of the C Users Group, which had approximately 150 members.

December 18, 1982 — The name was shortened to C Users’ Group Newsletter, and the first advertising was accepted. Subscriptions were $10 per year.

December 1987/January 1988 — The C Users Group Newsletter purchased The C Journal, started in 1984 by David Fiedler. The two publications were combined to become the C Users Journal, published in magazine format eight times a year. There were 6,800 subscribers and 3,000 newsstand readers; the subscription price was $20.

July 1994C/C++ Users Journal made its debut.

November 2001C/C++ Users Journal celebrates 20 years. Published monthly, CUJ costs $34.95. It has more than 43,000 readers worldwide and supports a bimonthly Java supplement, Java Solutions.

20th Anniversary Thoughts from CUJ’s Editorial Leaders

Robert Ward: Editor and Publisher, 1981-1995

The problem with anniversary issues is that they demand one think about trends. Twenty years is a long time — especially in the technology business. Yes, I love technology and am always amazed at what we’ve accomplished. (How can anyone who submitted card decks in 1970 not just shake their head in wonder over having a 512MB, 40GB, 900 MHz Athlon sitting on their desk?) Still, there’s an aspect of the trends that just doesn’t sit well with me.

I’m something of a minimalist. I take great satisfaction in doing more with less. I like hand planes and chisels, finite state machines, and wired ors. Minimalism isn’t quite the right word, though — at least not materialistic minimalism. Maybe it’s a form of craftsmanship — or just a love of tools. I take great pride in knowing how to use a wide range of tools well. I love designs, especially tool designs, that are the simplest, best possible fit to the task. A well made, well-tuned jointer’s plane, for example, in the hands of someone who knows how to use it, is without par for straightening an edge. A cabinet scraper (a simple square plate of metal) is the tool of choice for smoothing or cleaning a surface. Somehow I find the same satisfying elegance in a simple macro assembler, an oscilloscope, a logic analyzer, or a clean language design like C.

From that point of view, the trends don’t seem to be on my side. If C++ has an analogue in a hand plane, it would have to be the Stanley No. 55 Universal Combination Plane. This “planing mill within a box” had more parts than any other plane ever manufactured. It shipped with 50 some different cutters, standard, and there were 44 more available as an option. While theoretically the 55 could cut almost any profile, it was so difficult to set up and use that few owners used it as more than a simple rabbit plane. Today collectors love the 55 because, even through very few were sold, you can find many complete examples still in the original box. Sometimes I wonder, what if we could tell which C++ features had never been “taken out of the box”? Fifty years from now will C++ be a curiosity only a collector could love, or a still respected and copied tool like the Stanley/Bailey No. 5?

Recently I got the chance to do some serious embedded systems engineering and rediscovered my roots. I loved it. I found myself hustling to get to work a little early and being astonished when others in the lab started turning out the lights to go home.

I’m a classic embedded systems engineer. I love problems that are too complex to solve immediately, yet small enough that I can intimately understand every aspect of the solution, hardware and software. I like to have “control” over the entire problem. I like designing and building my own boards and, when necessary, building tools and “jigs” to support the work. I take pride in being self-reliant. I get frustrated when something threatens that sense of control: when I’m forced to use unnecessarily complex tools, or poorly designed and documented libraries; when I’m forced to call a vendor for “support.”

I have to wonder how the trends will affect my love for embedded systems work. It seems that cost, performance, and interoperability factors are forcing embedded designs to become more and more complex. This coupled with advances in integrated circuit fabrication is shifting the market away from board-level designs based on of off-the-shelf components and toward some form of ASIC.

At first blush, the design problem is the same: you’re assembling a solution by aggregating IP blocks instead of by aggregating IC components. In some ways, it’s just a convergence phenomena; hardware design is becoming software (VHDL) design. But the risk model is different and that changes everything. If I screw up a board design, I can probably patch the prototype and continue with the development effort — worst case, I’m out a couple of days and a few hundred bucks. If I screw up a tape out for an ASIC — oh, my! I just bankrupted myself and three generations of my descendants.

That risk changes everything. It changes the tool set. It changes the methodology. It changes the very focus of the project. The tools become enormously complex megabuck-per-seat monsters. Every design choice becomes driven by its impact on project risk. The “simplest tool that fits the task” becomes the tool that’s complex enough to analyze every possible eventuality. Everything, every step becomes focused on absolute, total, a priori verification of the design.

I used to think that to “prove my stuff,” I needed to be designing the next generation processor. Well, I’m older and wiser now. While the technology still impresses and fascinates me, I think I should leave this kind of engineering to someone else. It seems to me that there’s some fundamental conflict between the kinds of risks and solutions that satisfy my “self-reliant” side, and the focus on risk management needed in a successful ASIC project. I’ll continue to design and build embedded systems, but I’ll be happy to work on simple, deeply embedded board-level projects. I know things are changing rapidly, but even allowing for the trends, I’m pretty sure there’ll be enough of this work to keep me happy for years to come.

I wonder, though, where my kids will find their satisfaction.

P.J. Plauger: Senior Editor, 1990-2000

Has it really been 20 years? My earliest contributions to CUJ date back to the early/mid 1980s when Rex Jaeschke and David Fiedler cranked it out as a newsletter. I no longer keep those old articles on my laptop, so I can’t quote chapter and verse as is my wont. But I do recall that Rex was good at twisting my arm to elicit contributions, even at times when I felt way too overloaded to do one more thing. His persuasive abilities seem to have passed on intact to every succeeding steward of CUJ’s fortune, up to and including the present day.

I do recall a phone call from Robert Ward, back in late 1987, telling me that R&D Publications has acquired the newsletter. He didn’t quite take for granted that I was to be part of the acquisition, but did impose upon me to write a regular column on Standard C. I was already writing monthly for Computer Language, was overworked as Secretary to the ANSI C Standards committee, and was president of my own software company, Whitesmiths, Ltd. So it was the height of folly to take on even more work. But I did.

Little did I know at that time that I would go on to write columns for every issue of CUJ through May 2000. That’s 141 essays, each of about 3,000 words. Moreover, I also agreed along the way to write for Embedded Systems Programming and a quarterly newsletter that Rex continued for a number of years. So at the height of my column-writing binge, I was turning out 40 articles a year, or about one every nine days, month in and month out.

Tana and I sold Whitesmiths in mid 1988. After a year of working for the new owners, I was on my own as a professional writer. Next thing I knew, my good friend John O’Brien, who is still Managing Director of Whitesmiths Australia, landed me a one-year teaching gig in at the University of New South Wales, in Sydney. That was interesting enough in its own right, but another twist of fate made it more exciting. Just before I left, I agreed to become Senior Editor of CUJ.

I can’t say that Robert Ward twisted my arm to take the job. Perhaps his persuasion was too subtle for me to detect. All I know is, one minute I was commiserating with Robert because he was so overworked as Editor of CUJ and publisher of several magazines. Next thing I knew, I was volunteering my services. He accepted, obviously. Little did I know that I was signing up for a hitch of 10-plus years. Or that I would start yet another software company along the way, which would soon come to eat all my time. History repeats itself, particularly for those who never learn to say no.

But that’s just my little story. To me, the most exciting thing all those years was to watch CUJ grow in quality and in stature. Today, it is the pre-eminent technical magazine for serious programmers. As a writer turned editor turned reader, I’m pleased to find good stuff to read in every issue. All those years I helped shape each issue were rewarding, but even more rewarding is to see the magazine carry on to new things with no further help from me.

I suppose I could feel bad that CUJ continues to flourish without me, but I don’t. It’s very much like watching your child grow up and go off on his own. (And I have a son who’s in that very process right now.) You can feel pride at the good stuff he got from you and now perpetuates, regret at the bad stuff that rubbed off and at the other good stuff you failed to pass on. But mostly you celebrate his creativity and independence.

As one last vote of confidence, I should point out that our company, Dinkumware, Ltd., continues to advertise regularly in CUJ. Tana, as Marketing Director, has had no trouble re-upping with CUJ each year when she makes her ad budget. Not all publications are so lucky — she is a pretty demanding advertiser. For a magazine to flourish, it must strike a good balance between circulation and advertising revenues, between editorial content and the advertisers it attracts. CUJ keeps getting it right.

Live long and prosper.

Marc Briand: Managing Editor, 1994-1997; Editor-in-Chief 1998-2001

Happy Anniversary, CUJ! Since I edited this magazine in one capacity or another for seven years, I hope I can say I have contributed to its longevity. Beyond this, everything I have tried to write about CUJ’s 20th anniversary has come out sounding like PR — I fear I am still too close to the magazine to say anything objective about it. So, I thought it would be more fun to discuss the evolution of C++, upon which CUJ’s future assuredly depends.

I am somewhat at cross purposes here. As a former editor, I know that nothing is as exciting for a language magazine like CUJ as covering an evolving Standard. It gives everyone plenty of stuff to write about. So, when I first heard that the C++ standardization process was ramping up again, I started putting together my wish list just like everyone else. My list contained things like a better smart pointer (than dreary auto_ptr), garbage collection, a reflection facility, and more. But as a programmer, I don’t really want to see a bunch of new features added to C++, as cool as they may be. I would much rather see the standards committee go back and fix what’s in the Standard already. My reasons are partly pragmatic: I know it may be years before I see new features implemented correctly in a compiler that I can afford. So if it comes down to a choice between fixing what’s broken and giving me lots of gee-whiz stuff I can’t use, well, it’s a no-brainer as far as I’m concerned.

A few well-meaning C++ experts have suggested that the Standard should include graphics and multithreading libraries. Frankly, I think that idea is misguided. Standard libraries represent the lowest common denominator among platform differences that can’t be abstracted away. When it comes to something as platform-dependent as graphics or multithreading, that denominator can get awfully low. If a library is sufficiently crippled by standardization, no serious developer will use it; they’ll just go out and get a third-party library that works. This leads me to question the motives of those who would expand the scope of the Standard so radically. Do I detect a little Java envy here? Java may seem to offer tantalizing functionality, but look at what it doesn’t give you: interfaces that are consistent, interfaces that are guaranteed not to change at a designer’s whim, and functions and classes that have been determined to be essential by developers worldwide. In other words, if the designers of Java had taken the trouble to provide these things — which are expected of a standard library — Java might not have graphics and multithreading either.

If the C++ standards committee must add to the Standard, I wish they would add support for generic programming, one of the things that makes C++ truly unique as a popular language. Hey, C++ committee: we’re dying out here. Give us some help debugging this gnarly template code — or at least, don’t make it any harder than it already is. Give compiler vendors a chance to catch up and develop some decent template debugging tools. And while you’re at it, resolve some of the questions brought up by Chapter 14 (templates) of the Standard. For example, is every conceivable form of partial specialization automatically supposed to work? Or are there limits on what is expected of compilers? In the long run, cleaning up Chapter 14 would probably help us developers more than anything.

C++ is a great language, but our motive should not be to make it the language used for everything. That would just be silly, especially in an age that is becoming increasingly multilingual. Whatever else we might say about CUJ, I think it has done a pretty good job of resisting silliness and hype over the years. But if C++ goes off on another wave of invention, I am sure CUJ will help sort out the mess for developers. Oops! I guess I let a little PR slip out after all. Now that I have sufficiently antagonized the C++ intelligentsia, I’ll let someone else have their say.

CUJ’s Most Loyal Readers

Since our readers are the lifeblood of the magazine, we wanted to include them in this celebration by recognizing those who had been with us since the early days. We asked that long-standing readers send in a photograph of themselves with their earliest issue; in return, they would become eligible for a 20th anniversary t-shirt and a CUJ CD-ROM, and the photos could be published in this issue. The responses were inspiring, entertaining, and typical of the interactions CUJ has had with readers throughout its history. (Jay Jaeger caught us in an off-by-one error!)

The Winner

I humbly submit my entry into the contest for most faithful subscriber to C/C++ Users Journal (and predecessors). Please find attached a photo of me holding Volume 1, Number 1. I apologize for its horizontal orientation, but my son (the photographer) felt we could get more detail that way, making the front page more readable.

I first subscribed to the BDS C User’s Group not because of BDS C (which was an amazing compiler because it was so fast, so small, and generated good code), but to have access to the library (early freeware). Some letters indicate that I copied volumes for users because I had a TRS-80 and was able to translate disks. The requests were signed by Sheila, who worked with Robert (not Bob) Ward.

Thanks for your consideration.

Rodney Black

The Winner++

Please find attached my picture entry for your “20th Anniversary Contest.”

You will find, in the picture, myself, along with three documents to confirm my charter membership in the organization.

I am holding: C Users’ Group Newsletter, ISSUE 1, MAY 15, 1980. This is the original publication that started it all. As you can see from the date, your 20th anniversary party is over a year late!

On the music stand behind me are (1) a copy of the letter sent out when Robert Ward took over publication (one early submission to the library, “Adventure in ’C’” was submitted by myself and is listed in this letter), and (2) the inaugural issue of the BDS C Users’ Group newsletter, Volume 1, Issue 1, dated June 15, 1981.

BDS was dropped from the name of the organization in December 1982, in Volume 1, Issue 5. BDS was the name under which Leor Zolman published his 8080 C compiler: it stands for “Brain Damage Software” after the character in Doonesbury.

Jay R. Jaeger
Madison, WI

Honorable Mention

In the picture, that’s me with my Sept/Oct 1987 issue of the C Users’ Group newsletter. At the time, the whole magazine staff was six people, and it was still made in McPherson, KS by the Ward family. In the Volume V, Issue 2 (running 60 pages), there was the description of a slew of new packages released in the User’s Group library, and a notable article by Victor Volkman on the benefits of using Lex and Yacc to automatically generate parsers.

This issue is the oldest one I was able to track, and I hope that it qualifies at least for the oldest Italian issue. Since then I never missed an issue, so I have all 14 years of the evolving magazine. I like to think that it gave me a competitive edge and a whole new perspective on the practice of programming. I hope that the original spirit of the magazine (that unique passion plus profession mix) will be present also in the future.

Keep up the good work, guys!

Sincerely,

Massimo Cesaro
Padua, Italy

Here I am with the first issue of the C Journal (predecessor of the C Users Journal). This issue is from spring 1985.

Gaston C. Ceron

Morristown, NJ

Congratulations on Your 20th anniversary!

In the picture is me, my “first” issue, my “current” issue, and every single issue in between! And since I renewed my subscription just this month, there definitely will be quite a few “nexts” to come.

I don’t think that I will be your earliest subscriber, but in Holland there won’t be too many, as I don’t think the C Users Journal was on the Dutch market from the beginning. You might have guessed by now: I am Dutch and live in Almelo (10 miles from the German border).

My first Journal is from August 1989. I had been programming in C for over five years at that time. I remember that I was happy as a child when I first discovered the C Users Journal — dedicated completely to my favorite language!

I started programming C under CP/M with Toolworks C/80 and BD Software’s C Compiler (Leor Zolman). Did assembler, Basic, Forth, and Pascal before, but really got hooked on C. Don’t have to explain that, I think!

Bert Schonewille

Almelo, Holland


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video