C as first language?

Discussion in 'C Programming' started by toxemicsquire4@gmail.com, May 21, 2014.

  1. John Bode Guest

    Normally, C makes a *lousy* teaching language because it assumes you know what
    you are doing at all times. That's a bad assumption to make for experienced
    programmers, much less for people just starting out. Ed Post described
    TECO as a "you asked for it, you got it" editor (as opposed to "what you see is
    what you get"). C follows a similar philosophy, and won't necessarily warn
    you when you're doing something stupid. Think of C as a power tool with no
    blade guards, and just be aware that it *will* cut you at some point.

    However, since you're interested in systems-level programming, C is a good
    language to learn, since it exposes a lot of low-level concepts. It makes
    you aware of how your data maps to memory (at least at the conceptual level).
    It also makes you aware of memory as a limited resource.

    The main drawback of learning C first is that it wires you into thinking in
    low-level terms (not like assembler, but still...); this can be a hinderance
    when learning languages like Haskell, or even Java. A secondary drawback is
    that most C references are *crap*. A lot of bad practice and misinformation
    has metastasized in most books and tutorials.

    C provides no standard containers beyond arrays. For anything more complicated
    (queues, stacks, trees, dictionaries, etc.), you'll have to roll your own or
    find a third-party library. The benefit of rolling your own is that you learn
    how such containers work, and how different implementation strategies have
    different performance. The drawback is that you have to write, test, and debug
    all that code along with the code that works the actual problem.

    As for resources, my go-to desktop reference is Harbison & Steele's "C: A Reference Manual", currently 5th edition. Kernighan & Ritchie's "The C
    Programming Language", 2nd ed., is somewhat long in the tooth (doesn't
    cover C99), but is still a good introduction. Although I haven't used it
    myself, King's "C Programming: A Modern Approach" is recommended by people
    I trust.

    An online draft of the latest C standard (C 2011), is available at

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

    On its own it's not a great *learning* resource, but as you become more familiar
    with the language it will be invaluable.

    For my part, I don't do systems programming; I'm a dumb applications programmer who makes maybe one or two systems calls per project, usually to create a
    thread or something. I've never worked an OS kernel, so I can't give any
    guidance in that area.
     
    John Bode, May 27, 2014
    #61
    1. Advertisements

  2. Hans Guest

    Try "C for Dummies" by Dan Gookin. Perfect for real beginners.
     
    Hans, May 29, 2014
    #62
    1. Advertisements

  3. I can't directly comment on the book myself, since I've never read it,
    but you might check the reviews on amazon.com or on some other site.

    Some reviews say it's an excellent book for beginners, but another says
    it devotes less than one page to pointers, and less than two pages to
    structures. Other reviews say that the jokes and other irrelevant
    material are excessive.
     
    Keith Thompson, May 29, 2014
    #63
  4. Maybe a little low, but if you want to simplify it enough that someone
    can get started before learning everything, not so bad.

    I was remembering not so long ago, that I wrote my first OS/360
    assembly program before understanding base registers. (Fortunately
    I didn't write over the base register.) It was a Fortran callable
    function (C hadn't yet escaped from Bell Labs), and I followed a
    template that showed what comes first and last, and put what I
    wanted in between.

    One should be able to write at least one C program before one needs
    to learn about pointers, and maybe a whole first book full.

    In the early days of C, it was often both faster and smaller (code
    generated) to use pointer operations instead of indexing. That is:

    for(i=0;i<n;i++) *s++ = *t++;

    instead of:

    for(i=0;i<n;i++) s = t;

    (Yes, technically, s and t are still pointers, but you don't need
    to know that to write the loop.)

    Besides, it makes it easier if you need to use s and t later.

    Some people I know like the "Head First" series of books, maybe
    good enough for beginners, but not quite dummies.

    -- glen
     
    glen herrmannsfeldt, May 30, 2014
    #64
  5. J. Clarke Guest




    Might I suggest not going with just one book? If one has never written
    code before, any programming language can be overwhelming and the first
    run through can lead to more confusion than knowledge (I've seen
    experienced engineers come back from classes in BASIC convinced that
    programming was forever beyond them).

    Perhaps one should start out with the "For Dummies" book. That gives an
    overview of the landscape and an idea of what is happening and maybe
    lets one run some fairly simple examples.

    Then do the Head First, which is at a bit higher level than For Dummies
    and since one has seen the material before it's going to be a lot less
    overwhelming.

    Then perhaps work through K&R or Kochan ("Programming in C") or Kelley
    and Pohl ("A Book on C").

    Also there is a Schaum's Outline. Doesn't matter what the subject is, I
    learned long ago that if there's a Schaum's you get it and work through
    it on general principle. They're cheap and they're a good supplement to
    any text.

    In addition, try exercises from the sources listed at
    <http://programmers.stackexchange.com/questions/756/where-can-i-find-
    programming-puzzles-and-challenges>.

    Make up a project of your own and start working on it.

    Also, as a learning methodology--any time you see code in a book, key it
    into something and make it run. If it's not a complete program, making
    it complete teaches you something. If it is complete and you make a
    typo, fixing the bug teaches you something. And every once in a while
    what is in the book is bugged in itself--again fixing that bug teaches
    you somthing. And the process of running the code through your eyes and
    brain and into your fingers captures pieces that would otherwise be
    missed. And once it's keyed and working, there's always the temptation
    to play with it.
     
    J. Clarke, May 30, 2014
    #65
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.