When can I say I know how to program in C? [duplicate]

Question

Possible Duplicates:
When does one consider ones self an expert in a particular programming language?
How much time, in average, does it take to master a language?

Let's see.

I've seen in several places, including Advice for Computer Science College Students, by Joel Spolsky, that a graduated Computer Science student must know C.

How do I know if I know C or not?

I have developed a few projects in C (an implementation of the ext2 filesystem with FUSE, and a few others), but I suppose it means more than just knowing pointers, free, etc.

Answer 1

The Problem

The problem is the phrase knowing C is subjective. Some people think you can learn to read the syntax of a programming language and know it. Others think you need to know every little dark corner and gotcha to know a programming language.

I mean if you can read a menu in Spanish and figure out what to order at a Mexican restaurant, do you know Spanish? Or should you be able to translate any English document to Spanish and all the regional dialects with all the subtlety of each region's specific customs to know Spanish.

I know more than a few people that spent 4 years in high school learning Spanish, and can read it and pronounce the words correctly even with very convincing accents from different countries, but can't form anything more than rudimentary "where is the bathroom" type constructs on their own? The definitely do not know the language.

Subjective Opinion

My opinion is to know a programming language, means you have advanced knowledge of the language, you need to be able to sit down and write good idiomatic code that doesn't look like another language you learned previously.

It means you use modern best practices, it means you know how to apply common programming algorithms in the most pragmatic idioms available in the language.

I means you know when and where to look for the right answer for things you don't know for things like standard libraries and frameworks rather than re-inventing something yourself. You don't need to know everything, but you do need to know how to find out what you don't know.

To me know means you can write high quality code in the language, not just make something work.

For Example: Python that looks like procedural C code, just with Python syntax and doesn't use any Pythonic idioms is not written by someone that knows Python. You don't need to use lambda:, list comprehensions or crazy meta-programming constructs everywhere you possibly can, but know when to apply these idioms with restraint does point to that you know the language.

Knowing C means you should be able to write idiomatic C, that follows empirical best practices, no common newbie errors with = vs ==, no memory leaks, write includes that don't include everything over and over again, etc.

NOTE: Spanish is the straw man here, just like C is in the question. Replace Spanish with any other language, replace C with any other programming language, same subjective argument.

Answer 2

When the meaning of this is obvious:

while(*src++ = *dest++);

Then you know C. When you can tell that its wrong, then you really know C.

Answer 3

C isn't a big language and there are only a few 'design patterns' (horrible term but I'm not using paradigm in public)

If you have read K&R and understand pointers then you know C.

If you are comfortable with function pointer declarations and can write the quicksort compare function without looking up the arguments you are an expert

Answer 4

A great question for any language really. If you feel comfortable writing a program in C and spend more time writing code than reading K&R then you should go ahead and say you know C.

Answer 5

As with many programming languages, C is syntactically small, so you can learn the syntax in a day, and many of the idioms in a few days. But what makes a developer productive in a programming language is thorough knowledge of the standard library and of other libraries commonly used with the language; functionality, strengths, and weaknesses.

For example, I used to really know C++, but after years of not using it, and the changes to the standard and quasi-standard libraries done since, all I can say is that I'm well acquainted with the language.

The best way to get to really know a programming language is through study while working on a significant project that uses it. Participating on an open source project may be good because contributed code is very scrutinized in those; if your contributions are accepted, you know, and if they're accepted without amendments, you really know.

Answer 6

Knowing how to program C(or anylangue) isnt the big deal. Anyone can learn the syntax. How good are you at applying it , thats what matters. And that takes time. There is no quanitifiable leven for "good". You can always get better if you keep learning.

Answer 7

You know C if you can tell K&R something new about it. ;-)

When it comes to languages, knowledge is not about pointer-to-function-returning-pointer-to-array-of-functions-returning-this-very-pointer, it's about techniques, elegance and beauty.

I often compare programming to writing poems. There are some concise rules (that you may break) and there's something you want to express. It doesn't make you a good poet if you know the words in the language. Knowledge about grammar will also not be very helpful. Striving for beauty will.

That being said, here's an adapted version from a famous quote:

If one asks "How do I know if I know C or not?", and somebody answers, they both don't know.

"To make a prairie it takes a clover and a bee,
one clover, and a bee,
And revery.
The revery alone will do,
If bees are few."
(Emily Dickinson)

Answer 8

You know C when you understand Duff's Device.

Slightly adapted (to match modern C) from Wikipedia:

void send(short* to, short* from, int count)
{
        int n=(count+7)/8;
        switch(count%8){
        case 0:       do{      *to = *from++;
        case 7:               *to = *from++;
        case 6:               *to = *from++;
        case 5:               *to = *from++;
        case 4:               *to = *from++;
        case 3:               *to = *from++;
        case 2:               *to = *from++;
        case 1:               *to = *from++;
                }while(--n>0);
        }
}

Answer 9

Actually, I think that Spolsky's advice on learning C had to do with the fact that knowing C means that you understand low-level concepts that are common in all the operating systems, runtime environments, libraries, etc. that we use everyday (caused by the fact that they are practically all implemented in C).

Some of these concepts are related to how computers are physically implemented and programmed at the lowest level (microcode). This refers to things such as the amount of bits in an integer being related to the register size of a processor, why you can run into weird errors if you use floats to calculate integers, when and how to deal with endianness, etc.

Some things however are actually related to C itself, in the sense that the way K&R encapsulated some of these things causes some bugs or program behaviours to be more common than others. For example, code like if (x = y) {...} can linger in systems for years. This refers to recognizing when a problem or behaviour is caused by such a bug.

Doing lots of C programming and causing, encountering, dealing with and solving these issues in practice eventually adds up to knowing C.

Answer 10

You know a language when you know why a language does certain things the way it does. For example, you know why declaring a function parameter as T a[] is equivalent to declaring it as T *a, or why you can subscript a pointer, or why statements like i = i++ are bad juju.

Answer 11

When not only you can produce working non-trivial code, but also when you become familiar with implementation-defined behavior, undefined behavior, details of each compilation phase (preprocessing, compiling, linking), reserved names, and sequence points.