Re: Learning C Programming

["Steven J. Owens" <puff -at- NETCOM -dot- COM>]

Rowena Hart writes:
> --> I don't have any plans to change careers and become a C programmer.
> I DO plan to acquire enough programming knowledge and skills to be a
> better technical writer.
>
> --> I chose C because the programmers I work with use C.
>
> --> I also chose C because I want to focus on concepts and
> structures, which is something that C has in spades.
>
> I know it's a hard language to learn, but I'm willing to start with it.

     These are all valid reasons; I think one of the reasons I had a
better time communicating with the engineers at one of my first "real"
techwriting jobs was because my first job at the company was to write
the online help system - in C :-).

     I'm sure they knew I wasn't a genius programmer, but the code I
wrote demonstrated that I at least had a fundamental understanding of
what their job was.  I also made sure that I always kept a positive
outlook and an interest in learning more about programming, as well as
about the product.  I think this helped them establish a frame of
reference in their minds for communicating with me.

      Some concrete suggestions:

     1) I highly recommend Kelly & Pohl's _C by Dissection_, as a good
introduction to C and a slight introduction to C++.  I surveyed a large
number of C books in 1992 and _C by Dissection_ was the one that made
the most sense to me.  It taught by discussing a concept, discussing an
example of using that concept, providing a code listing demonstrating
the example, then dissecting the code listing, statement by statement,
to examine how it works.

     I don't know about books that've been published since then, but
_C by Dissection_ will always be a fond favorite.

     _C by Dissection_ ends each chapter with a brief discussion of
C++ features related to the chapter topic, and has an appendix
summarizing C++ features at the end of the book.  Note that this does
*not* deal with Object-Oriented Analysis/Design/Programming issues;
there are many books on this, I'd suggest you start by reading some of
the many FAQs on the Internet related to this.

     2) For your purposes, it's probably a good idea to use the
environment your programmers are using.  Also, see if you can interest
one of the programmers in mentoring you through the process; if you
can enlist one, then you might consider going to management and
getting some official support (at least to the extent of approval to
use company systems for your work; possibly getting them to pay for
books, or even classes).

     3) Caveat the above, I'd suggest you get one of the visual C/C++
IDEs (Integrated Development Environments).  This will allow you to
learn and play with fun, spiffy GUI visual programs, which is a bit
more fun than plain old text-interface programs.

     4) I'd also suggest you get _Code Complete_, by Steve McConnel,
for an introduction to some of the theoretical issues of software
development.  In fact, _Code Complete_ is on my general recommended
reading list for any programmer or writer who works with programmers
or software development.

     5) Programming, per se, breaks down into several broad topic
areas.  Here's a list, but note that it's not in order of learning
nor in order of importance;  many of these are typically taught at
the same time, some are not taught formally but are expected to be
absorbed while the others are being taught.  A real programmer is
more than the sum of the programming languages he or she knows.

     logic
     structure
     math
     language syntax
     algorithms
     data structures
     programming methodologies
     project management

     Taking a course or reading a book on logic and symbolic logic
will help you prepare for learning to program.  I did this and it
helped quite a bit.  Unfortunately, I didn't take any of the
programming-related math courses, which still hampers me on occasion,
even though I tend to stick to "lightweight" programming projects.

     Language syntax is far more than knowing a few or even several
programming languages; a good programmer is familiar with the
underlying logic of language design and can quickly pick up new
languages, having internalized the structures and broad syntatic
issues and being able to fit a new language into those.  This is part
of why good programmers don't tend to like "messy" languages like
VisualBasic.  They weren't designed in the real sense and hence don't
click as well with those internalized structures.

     Is there an easy way to get this knowledge, a way other than
learning many different languages?  Maybe.  As one poster here pointed
out, you could start with an easier language, designed as a learning
language, and then jump from there to C.  Or you might be able to find
a good book that looks at the design issues; I can't think of one
offhand, if anybody else can, I'd like to hear about it.

     [ One of the better experiences I had learning a new language was
a C-like language (ColdMUD, if anybody's interest) where the language
spec was laid out in terms of "this is the statement syntax; these are
the flow control structures; these are the logic structures; these are
the data structures; etc".  You may find it beneficial to find and
skim a book that examines C from this light, before you plunge into
actual programming.]

     Aside from being able to express commands in a logical fashion,
being able to translate those commands into the programming language
syntax, and being able to arrange the code in structural fashion, you
also need to understand data structures and algorithms.  Most of the C
books you look at are *not* going to address this latter topic well,
and you'll continually run into your shortcomings if you don't address
this.

     Donald Knuth has written several very weighty tomes that are the
bibles of serious programmers; however, they're extremely dry and
mathematical.  There are various books on algorithms and data
structures; the two topics are usually intensely inseparable.  I
haven't any specific recommendations, though experienced programmers
have recommended the one by Aho, Hopcroft and Ullman.

     In general, these books are often written giving examples in the
author's favorite language, or in some sort of artificial
pseudo-language invented for the book.  I recommend getting one that
gives the examples in C. One that happens to be on the shelf near me is
_Data Structures Using C_ by Tenenbaum, Langsam and Augenstein.  No
idea how good it is, though the guys who worked out of this office
before me are said to be excellent programmers.

     Having looked at a book and chosen it, before you buy, check
around on the net, look at the reviews on Amazon, search dejanews,
check the C newsgroup FAQ, and see what opinions are about the
accuracy of the book.  Often I've heard horror stories about broken
examples in the books, which can lead to really frustrating times for
the student who doens't realize they're broken.

     My writing background has worked hand-in-hand with learning about
programming methodologies - which has fed back into thinking more
carefully about writing methodologies.  A lot of the materal in JoAnn
Hackos' _Managing Your Documentation Process_ came out of the SEI
(Software Engineering Institute)'s research on software development
processes.  _Code Complete_ has a lot about both software
methodologies and software project management.

     Some (or most) of the different methodologies may have a lot of
popular support on the web, so check around, you may find web sites
devoted to promulgating the methodology, FAQs, etc.  Some of the FAQs
can make the easiest reading (this might be worthy of the subthread in
itself; FAQs are an interesting case of evolutionary documentation, or
documentation by statistic; whatever questions keep popping up get
added to the FAQ.  Maybe this is why they're so useful :-).

     You may also find reading the CACM (Communications of the ACM
(Association for Computing Machinery), a Computer Science academic
journal) useful, as well as the IEEE Software journal.

     You can feel free to e-mail me with questions if you get stuck,
but C is not my main language these days (Java and Perl are) and in
any event, I may not be able to respond immediately to questions.  If
anybody wants to take a crack at learning Perl, I have a list of books
to get and read... :-).

Steven J. Owens
puff -at- netcom -dot- com

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=