C as first language?

[John Bode]

I'm learning C right now as my first language(I've done functions, loops,
data types, if/else), and I'm wondering if I'm going the right path. I've
heard alot of good stuff about C, like how it's super fast and simple to
learn. I've also heard alot of bad stuff about how it's old, busted, and
non-object oriented. I'm a linux user(Arch/Gentoo), and I want to get started
on a project after I'm done learning. I want to join an operating system
project and help in it and stuff(I really like the whole idea of operating
systems and how many layers it has), but I want to make sure I'm getting the
right stuff so I could learn what I need.

What do you guys think is the benifit of learning C first? What would be a
drawback?(BTW: I'm totally fine with the manual memory thing(it turns me on
(I know that's a bit weird, but I'm a linux geek)) and I'm willing to learn
it). What would be some good sources of learning? What practices should I
avoid? What OS projects would be good for a beginner?

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.

 

[Hans]

You are.

Normally, I would recomment English as a good language to learn first (or next)
for the average troglodyte who posts here, but you seem okay in that
department.


C is simple to learn. C is not quite so simple to learn to use effectively,
while avoiding pitfalls.


Object-oriented programs can be written in C: you get to design the plumbing
of your own object system. There is little support from the language.

Some C programs exhibit considerable OO design, with patterns which are closely
analogous to inheritance, encapsulation and polymorphism. For instance,
numerous areas of the Linux kernel.


The benefit of learning C is that it's the most successful representative and
descendant of that family of languages which includes Pascal, Modula, Algol and
their ilk. Once you learn C, you have that whole thing covered.

C has become ubiquitous for expressing system level programming interfaces, so
if you understand C declaration syntax, that is helpful when using other
languages, which necessarily have to have bindings to C interfaces for
sheer survival.


The C Programming Language (second edition, Kernighan and Ritchie)
C: A Reference Manual (Harbison and Steele)


C Traps and Pitfalls (Andrew Koenig)

(this is a book based on a much shorter paper from 1989 of the same name).


Xinu, Minix, ...

Try "C for Dummies" by Dan Gookin. Perfect for real beginners.

 

[Keith Thompson]

Try "C for Dummies" by Dan Gookin. Perfect for real beginners.

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.

 

[glen herrmannsfeldt]

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.

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

 

[J. Clarke]

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.

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.

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.