[aclug-L] Re: c primer

[Bruce Bales <bbales@xxxxxxxxxxx>]

I tried to reply twice and got both messages back "Undeliverable mail."

I have been dabbling in C for 20 years, took several classes in C, and written
some simple programs, but never used it seriously.  Since beginning working with
Linux, I have taken a new interest in C.  Some of the items in Tom's list have
caused me trouble and I believe I would benefit from what he proposes.  I, for
one, would like to see it.
bruce



Tom Hull wrote:

> I'm not sure how to respond to this, but since this was the only response to
> my C session proposal, maybe I should just throw a bit more fuel onto the 
> fire.
> (Ashes, whatever.)
>
> My main point is that: if you want to learn to write non-trivial programs in
> C, the most critical thing that you have to master is the type system, and
> this is also the most difficult thing that you have to master. However, much
> of what makes it difficult is that it is actually simpler (cruder, more
> primitive) than you might expect. This simplicity also makes it possible
> to do a presentation on it that might conceivably fit into a single night's
> program. At least that's my opinion. I've never tried to put together such
> a presentation, and I've never seen a book which presents this material in
> a way that is as simple and clear as I think should be possible.
>
> Now, the question of whether you want to learn C, or why you should want to
> learn C, that's another question. And the other question you raise, how to
> introduce beginners to programming, that's yet another question -- and one
> that's not necessarily addressed through C.
>
> Consider the following list:
>
>  1) assembly language
>  2) C
>  3) C++
>  4) Perl or Python
>  5) shell (bash, ksh)
>
> These are all general purpose programming languages, listed from the lowest
> to the highest level. By level, the main thing we mean is how much work you
> can do with a single command (higher level is more), and how much detail
> control you have over that work (higher level is less).
>
> Now, where you start in this hierarchy depends on what you want to do. I think
> the two main reasons for anyone to start programming are empowerment (the
> ability to get things done) and enlightenment (the ability to understand how
> they work, and why). In general, if empowerment is more important, start with
> a higher level language -- either general purpose or something specific to
> what you're interested in, which could be SQL or some application-specific
> scripting language. If enlightenment is more important, start with a lower
> level language -- which probably means C. (Hardly anyone actually writes in
> assembler anymore, and you're unlikely to run across it except in the lowest
> level of machine-specific coding, or in debugging applications in very dire
> straits [kernel, or no source code].)
>
> jg wrote:
> >
> > Hi...
> > Well, I personally wouldn't know how many people in the group have
> > "any" interest in this. I do know that learning C "first" would be a smart
> > move for anyone wanting to learn any other modern computer language. If
> > the topic of C programming were limited to a one night presentation and
> > there is interest in C concepts, your plan sounds good. If there is no
> > interest, than maybe a more beginner introduction would be better in order
> > to introduce non-programmers. By "beginner, I mean talk about suggested
> > books to buy/read.
>
> If you want to learn to program, one of the best things you can do is to
> read real programs. Nobody has managed to distill these into books (except
> maybe Donald Knuth). The things that show up in books are illustrative
> fragments, not real programs. Most of them are worthless.
>
> > Discuss why the C language is important. How it
> > differs from other languages. Why it is used more for UNIX than for
> > Windows.
>
> Not true. C is fundamental to Windows (although Microsoft has done some
> hacky things to it). MFC is a C++ abstraction on top of the C WinAPI.
> VB is a primitive widget-builder plus a bunch of sludge on top of C.
>
> > Also discuss the relationship between C, C++ & Java.
>
> C is mostly good for implementing simple procedures, but you have to be
> very conscious of and conscientious about memory. C++ handles some (not
> all) of the memory issues for you. It also lets you think in terms of
> higher level constructs, like objects, classes, frameworks, patterns.
> This is great if you're merely a user of these things, but can require
> a lot more thinking to design them reasonably well.
>
> Java always struck me as a solution in search of a problem. I've never
> found the problem, so have no idea what it's good for. It is, superficially,
> a simpler and cleaner object-oriented language than C++.
>
> > Also, how much does C have in common with Perl, Python & TCL.
>
> Nothing important. What's important in C is the type system, the memory
> model, function calls, and the scoping associated with them. HLL's bury
> all of that. (There are, of course, generic programming concepts that
> almost all languages share, and some common function names -- Perl in
> particular has built-in functions which map fairly closely to the Unix
> API.)
>
> Think of it this way: for every line of TCL that you write, something
> like 50 lines of C get executed. The good news is that you didn't have
> to write those 50 lines; the bad news is that you don't really know
> what they do, whereas if you had written them you would know what they
> do. As long as TCL works, that's probably a good tradeoff, but when it
> doesn't work, someone's gotta dig into the C. The guy who wrote TCL
> wrote it in C. (Same for Perl and Python.)
>
> > Perhaps a presentation
> > on "Introduction to Programming" would be better (with the discution
> > revolving around C).
>
> I think "Introduction to Programming" should start with a higher level
> language, so you can do something quickly rather than drown in details.
> TCL/TK might be good for that.
>
> > On a different (2nd) night, a presentation on "The
> > Concepts of C" (like proposed in your e-mail, below).
> >
> > This weekend, I researched the books that are available for C.
> > I came up with a list of three of the best tutorials:
> > 1. "C Programming: A Modern Approach"
> > 2. "Pointers on C"
>
> I haven't seen these books. From amazon.com, they look big and expensive.
> I can't imagine writing 600 pages on C.
>
> > 3. "The C Programming Language, 2nd Edition"
>
> There's also a companion "C Answer Book", which provides solutions for
> all of the exercises. The two books can be quite effective together.
>
> > Best Reference:
> > 1. "C: A Reference Manual"
> > Best Style Book:
> > 1. "The Practice of Programming"
>
> My favorite C book is Donald Alcock's "Illustrating C". It's 214 pages
> long, and designed like a comic book. The pictures help, and the code
> samples are non-trivial. It also works as a reference. It's also out-
> of-print.
>
> BTW, throw away any C book which uses scanf() in the first 25% of the
> book.
>
> > One night cannot teach C, just like C in 21 hours can't be done.
>
> I'd think one could do a complete survey course on C in 21 hours.
> Your mileage as a student may vary, but everything could be covered,
> and most people should be able to learn most of it. It's really not
> that complex or difficult.
>
> > But, we
> > are a group of volunteers trying to help each other. The most we can do is
> > help point ourselves in the right direction (even though the concept
> > of the word "right" has become politically incorrect).
> >
> > James G.
> >
> > On Wed, 25 Oct 2000, Tom Hull wrote:
> >
> > > At the last ACLUG meeting, James G. asked for someone to do a presentation
> > > on the C programming language. The general reaction seemed to be: not in 
> > > one
> > > night. I've been thinking about this, and I think I could throw together
> > > something on a limited subset of C, specifically:
> > >
> > >   -- object types and their memory representation
> > >   -- type descriptors
> > >   -- casts
> > >   -- rvalues and lvalues
> > >   -- array and pointer operations
> > >   -- simple (non-bitfield) structures and unions
> > >
> >
> > > My question is, would this be of sufficient general interest?
>
> --
> /*
>  *  Tom Hull * thull@xxxxxxxxxxx * http://www.ocston.org/~thull/
>  */
>
> -- This is the discussion@xxxxxxxxx list.  To unsubscribe,
> visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi


-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi