>>7
Don't listen to
>>9 this guy. Actually, never listen to such retards.
First, don't join
comp.lang.c. Don't even come close to the mere idea of joining -any- Usenet group, but, specially, don't do it for any programming language discussion groups. There are a series of reasons for that, but I'm pretty sure you wouldn't do it anyway, and are not interested in details. In particular, the (unreceptive) people there will not give you any good advice, and may sum into your frustration to learn C. C is, unfortunately, the very kernel of a long-dated, fanatic cult.
Second, tutorials are a good way to grasp what programming is all about, but a very bad way to properly learn something. Avoid tutorial-learning. Fetch a good book (K&R comes to my mind) and read it, practising a lot while you do it. C is a language that, albeit not complex, requires deep attention to some details. By developing this kind of attention, you'll also be developing important skills that the average programmer actually lacks: strictness, corretude and acute reasoning (in contrast to lazy thinking and carelessness).
Another important aspect of learning is good contextualization. The C programming language was invented in the Unix world, and is still strongly bound to it. Therefore, it is important to know why it was invented, what were the restrictions and the limitations at that time, and what were the goals. You'll be in contact with the SUS standard and some auxiliary tools (such as
make and others), which, albeit not strictly related to ISO C, are invaluable tools to the programmer and is in sole agreement with the overall Unix and C philosophy.
Third. After you've been through the basics and developed a number of small projects, I consider it invaluable to actually read the C standard (the latest one). It is not a lengthy or heavy read and will serve as a groundbase for other important standards (such as the forementioned SUS). Most programmers don't read such important documents, and fill the community with bad-written code, which tends to give more woe instead of more joy, specially if such software goes into wide usage.
These standards should give you some vision with regards to corretude and portability, and should also give you a feel of what "standardization" is about. However, standards should not stifle your creativity to overrule them whenever you feel like doing so: at this step, you'll be actually developing good sense to make your decisions based on your arguments, necessities and taste.
Last, do one thing at a time. There's a
lot to read. Don't overwhelm yourself with dozens of documents or projects. Don't mix algorithms with syntactical learning. Don't relate OS concepts with language keywords. Trace and detect the boundaries of every single topic you're dealing with, and afterwards connect the concepts accordingly, instead of mixing all of them in the same cooking bowl. Know how to differentiate the language from the environment, from the implementation, from the toolchain, from the OS, from the algorithm.
If you go through these simple steps, you'll be not even an high-above-average C programmer, but actually an outstanding programmer in every other language or environment you will face in the future.
>>5
Very good one!