Ask HN: Should I learn C?

I feel compelled to add that I tried to learn C from a half dozen other books over several years (starting in childhood, so it was probably a bit early), but it never made any sense until I worked through K&R. Suddenly, C seemed like a beautiful and simple language (which it is). There are many subtleties, particularly in the macro system, that are not covered at all by K&R, but it is, by far, the best choice for learning C.

In other words: Don't waste your time trying to learn from anything other than K&R, at first. It's just the most concise text available...C is a concise language, and it is not well-served by big fat books.

Yes.

I'd say "It doesn't work well in most shops" is a damn good reason to not use something.

In general, very little of the program needs to be written in C to get great performance gains.

Additionally, python is vastly different from LUA. Lua is still a scripting language, ruby and python have moved past that.

For someone at age 18 or so, I'd say C is a much much better level of complexity to be tackling that C++

ISBN for anyone interested: 978-0130340740

Yes! In general, when asked "should I learn X | X is something that gives you a different perspective" the answer should be yes. In particular, C is excellent as it teaches you things must be understood even if you work with higher level languages: dealing with pointers, dealing with raw memory (allocation, deallocation, finding leaks), dealing with the I/O and VM sub systems of your operating system, understanding abstract data types.

On the educational side, you will learn about hardware works. Some will argue that there are better languages to learn these things and I'll agree: Forth could be better for learning about raw memory addresses and systems programming. Scheme could better for learning about data abstraction. However, C has several salient things going for it: C is UNIX (for good or bad, majority of serious non-embedded -- and even great deal of embedded -- programming outside of Microsoft or of Windows Desktop Application development targets UNIX) and C is the lingua franca of programming languages.

From the practical side, you will have an advantage too. Higher level languages generally still have pointers (Quiz: is Java pass by value or pass by reference? Answer: It's pass by value, just the value of anything other than the primitive types is a pointer). Higher level languages have built abstractions around I/O and VM but they typically fall under two categories: thin wrappers around C and POSIX APIS (Perl, Python, Ruby) or leaky abstractions that occasionally force you to use FFI to C (JVM based languages). In either case, if you are able to program C you have a competitive advantage against coders brought up purely on those languages.

C is also a good language to learn about data structures: partly because learning data structures in C is really about the data structures, abstract data types and algorithms and not (as C++ and Java centric courses often make it out to be) about OO. This is the book I recommend for data structures in C: http://www.amazon.com/Data-Structures-Pseudocode-Approach-C/... (I'm biased as I learned from it myself and have had classes taught by Professor Forouzan).

Note, I never said anything about performance. Just like it's nearly impossible to hand-write assembly that beats "gcc -O3" (not to say "gcc -O4" or icc) performance wise on modern hardware (out of order execution, NUMA, specialized instruction sets), I am pretty confident that languages will emerge that will beat C even for things like inner numeric loops by being able to reason more about mutability, side effects or lack thereof, exploiting parallelism and caching available in hardware. You won't be writing in C to make computation faster, you'll be writing in C to deal with I/O, memory and the like more efficiently: many times that will mean your code will run faster, but it won't specifically due to being written in C (to be blunt, it will be due to implements of runtimes and programming languages sheltering the languages/runtimes from the hardware/OS; that may not always be the wrong thing to do). See http://pl.atyp.us/wordpress/?p=2947 for a great discussion on this.

Finally in terms of C++: don't study it before knowing C and a non-C++ object oriented language. I was lucky enough to learn C before learning C++, but it was the first object oriented language I tried to learn. Because of that, I thought of OO as a black art. Oddly enough I truly learned about OO in Perl: I was writing Perl 5 (loosely adhering to Damian Conway's "Perl Best Practices") and despite OO in Perl being an ugly hack (it's similar to Python's, but without even the syntactic sugar that hides __dict__ away) the Perl code I was writing was far more OO than any C++ I wrote up until then. I then learned Python and Java; when I came back to writing C++, I was much better at it. Josh Bloch (along with Doug Lea, the author of Java's collections) in "Coders at Work" spoke of a similar experience (in his case, he didn't do any OO programming before Java) and likewise speaks very favourably about C.

I strongly recommend you do the same: learn C and do a non-trivial project in it (writing a compiler for subset of C in C did the trick for me) to truly grok it; continue building projects in Python (or another OO language e.g., Ruby, Java, Scala, Smalltalk, ObjC, Common Lisp+CLOS; pick as many of these as you'd like) to make sure you have a firm grasp of OO before you go after C++.