"C" What A Difference A Myth Can Make?
By Jeff Robinson

With IBM's announcement of support for ISO-C within the TPF environment, its almost inexcusable for any TPF programmer to avoid learning this industry standard computer programming language. But the sad fact is that "C" looms as an ominous, dark, unwanted cloud in the minds of many TPF purists.

Furthermore, for many years I believe those same purists have secretly and shamelessly rejoiced in the failure of TARGET(TPF) (the previous TPF/C language environment) to garner widespread support from the rank-and-file TPF community. It all makes me wonder why there's been such a lack of support and seeming opposition for a product that's already taken the rest of the industry by storm. Following are a few theories I have on the reasons and why you shouldn't be taken in by it.

The Silver Bullet Myth
At its first incursion into the TPF world in the late 1980's, TPF/C support was hailed as the "silver bullet" of any and every TPF development problem. Coding in "C" would be easier, quicker, and better in every imaginable way. Improved time-to-market, increased product quality and easier code maintainability would be the inevitable result of maximizing use of the new TPF C/370 environment.

Then, I believe that when many shops tried out TPF/C and it didn't solve all their productivity problems, they were disillusioned with the idea of using "C" as their core development language. This is unfortunate because many managers failed to recognize one simple fact which I'll illustrate: If your car is a "lemon" before you put new tires on it, it's still a "lemon" after the new tires are on. In other words, programmers who had problems being productive before they started coding in "C" will continue to have those same problems after they start.

This "silver bullet" myth is an analogy to the horror flicks of the fifties and sixties and how the firing of one silver bullet into the heart of the menacing Werewolf would undoubtedly put an end to the monster. However, in the world of software development, its long been proven in many industry studies that there is NO silver bullet. There is and never has been one single solution to solving the dreaded, menacing software development life cycle.

The "What Language Do You 'Think' In?" Theory
When I was taking Spanish 101 back in my college days, my instructor was a Nicaraguan national who spoke both Spanish and English fluently. Once I asked her which language did she "think" in or see in her mind when she communicated on a day-to-day basis. Her response was Spanish. She added that whenever she spoke in English that she'd sometime have to think of the Spanish equivalent first.

On my first big TPF/C project in the early nineties, it was evidenced to me that many of my co-workers should have been asking themselves this same question because it showed in their work. Most career TPF programmers had a difficult time making the transition to become TPF/C programmers because they couldn't stop thinking in terms of TPF Assembler code.

In one early incident, two programmers decided that they absolutely had to have the 370 Assembler instruction TM (Test under Mask) while coding in TPF/C. So, they spent time writing an equivalent TM function to be used in their "C" programs. Now, any good "C" programmer (not just TPF/C) knows that the designers of the "C" language provided an easier and quicker alternative to testing bits within "C".

Another programmer confided in me that he had to design all of his code in Assembler first and then convert it to "C" Language! Obviously, these kind of tactics are very time-consuming and can only hurt one's productivity. Most experts agree that its best to "think" in a neutral, high-level pseudo-code language. That way, it becomes easy to switch back and forth between any computer language such as "C", "FORTRAN", "REXX" or even Assembler when one needs to.

The "Steep Learning Curve" Defense
Some TPF'ers I've talked to will yet reason that "C" has a steep learning curve which doesn't pay-off in the long run. They list "C"'s cryptic command structure and ubiquitous set of confusing operators as reason enough to stay away from it for as long as possible. And its true that for beginners "C" might seem pretty intimidating. But I think its like anything new that one must learn: you start with the simple and work your way up to the complex.

Unfortunately, "C"'s reputation for having a difficult learning curve is aided by those same programmers who wanted to make TPF Assembler seem difficult and make themselves look smart. Thus, you have "C" programmers who violate what's considered 'good' rules of programming just like they did when they coded in Assembler. Unfortunately, the result is spaghetti code with very few comments and zero maintainability.

The "C" Path Length Problem
Finally, I think the biggest reason some people give for not trying out "C" is because of the increased path length and other overhead which is not present when using pure Assembler. However, this problem exists whenever and wherever you have a high-level language being converted to machine code. This is the trade-off for the other advantages that using the language gives you. Nevertheless, I believe that careful and conscientious designing/coding can help minimize this problem.

A Few Tips
For those readers who are not intimidated and have decided to learn and master the "C" language, here are a few pointers I'll like to share with you to aid you in your journey.

1. First, master the art of high-level design.
There is an excellent book I can recommend which addresses analysis and design for procedural-type languages such as "C": CODE COMPLETE, by Steve McConnel (Microsoft Press, 1993). Because of the way its written, you don't have to read the entire book but can pick and choose your areas of interest.

2. Get a "C" compiler and Start Coding (after you learn it, of course)
"C" is a language you can only learn by doing. If you don't use it you'll lose this knowledge fast. There are a plethora of products out there on the market to choose from. So, acquire one and start a little at-home project. OR...

3. Get on a "C" project at work.
Many shops are experimenting with "C" and some have at least one project going on. If you do get on a team project be very cautious: you'll find at least one "smart-guy" programmer who'll want to show off his "C" skills by speaking complex "C" jargon and writing code that only he can (or wants to) maintain.

4. Join a "C" Programmers Interest Group or Bulletin Board.
Doing this can help keep you interested in the language and may serve as a way for you to learn invaluable "C" coding techniques and tricks. At the very least, you can check out and post messages to ACP/TPF Today's C/TPF Discussion forum on the Worldwide Web at "http://www.tpftoday.com".

5. Finally, pace yourself in your effort to become a "C" Expert.
Don't try to learn to much at once or you may burn yourself out. If you're exposed to "C" regularly, you'll find that you're an advanced programmer after about 6-months. You'll be an expert when you can read and understand JAVA code without squinting. (JAVA, by the way, is based upon the "C" and "C++" languages -- another reason to Learn "C" NOW.)

If you're interested in reading about improving the software development cycle using "C" or any other language, buy and read the book: DECLINE AND FALL OF THE AMERICAN PROGRAMMER by Edward Yourdon (Yourdon Press, Prentice Hall, 1993). I believe that this book would be excellent reading for any software developer or manager.

If you have any comments/questions about this article, please email me at "profjrobin@aol.com". Special thanks to Johnny Holden for his gift to me of the aforementioned book and to Robert Gotham for our many thoughtful and enthusiastic discussions on the "Silver Bullet" myth.