Learn C

For anyone who hasn't browsed through Peter Seibel's "Coders at Work," one of his subjects is Fran Allen...it's kind of funny because I do agree that learning C has been valuable to the high-level programming I do today (but only because I was forced to learn it in school). But there's always another level below you that can be valuable...Allen says C killed her interest in programming...not because it was hard, but because of, in her opinion, it led engineers to abandon work in compiler optimization (her focus was in high-performance computing):<p>(Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming (Kindle Location 6269). Kindle Edition: <a href="http://www.amazon.com/Coders-Work-Reflections-Craft-Programming/dp/1430219483" rel="nofollow">http://www.amazon.com/Coders-Work-Reflections-Craft-Programm...</a> )<p><i>Seibel: When do you think was the last time that you programmed?</i><p><i>Allen: Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue....</i><p><i>Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels?</i><p><i>Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities.</i>

This is a fair point, but it brings to mind another point I didn't really understand till the last couple of years. Learning about how compilers work is just as important. Building a small lisp compiler was a life-changing experience for me in terms of going one level deeper, as much as understanding C was. For those who've never written lisp before, the reason I recommend a lisp compiler is that lisp compilers are the simplest to write, and the most expressive in terms of runtime strategy since lisp syntax mirrors a compiler's IR (intermediate representation). I think this is just as important in todays world because languages like Ruby and Javascript are both directly inspired by lisp. We also live in a world where Clojure is seeing a steady rise, for once a Lisp with large potential for significant commercial adoption.<p>I can highly recommend the book Lisp in Small Pieces, $93 on amazon, and worth every penny. Walking through the building blocks and design decisions of a language changes the way you code. Every language you look at winds up being internally translated into your own IR whether you've written a compiler or not. Understanding the inner workings of a compiler however adds depth.

<p><pre><code> You'll learn to feel every line of code you write </code></pre> This is <i>exactly</i> how I felt when I started writing C.<p>I started out with .NET and Java. Both had quite high abstraction levels, and not much deep integration with hardware. I took my control statements, conditionals, and high-level object-based programming for granted -- I never WANTED to learn C. I took one look at K&#38;R and was turned off by the insane amount of low-level work you had to do compared to Java or Python, even to write a simple character counter.<p>I came back to it. I was slow at first, I was confused, but I learned how to write in C. I learned how to control memory myself. I learned how to do my own text handling. I learned how to avoid buffer overflows and segfaults.<p>In many ways, it's like going from a Mercedes-Benz to a Miata. There's a lot less comfort, and you have to do a lot more of the shifting and oversteer yourself when the Benz used to do it for you, but you really <i>feel</i> yourself driving, and when you step back into the Mercedes, you feel numbed.<p>It's the same with C.

We need <i>less</i> code written in C, not more. We already have a problem with a massive, unreliable, insecure ecosystem of legacy C code that is hard to escape; writing more software in C makes that problem worse.<p>Most software is written to solve high-level problems. Using a high-level language is sensible, time-saving, budget-saving, improves portability, and saves on headaches later. The same rule that applies to COBOL should apply to C: only use it when you have to deal with an existing legacy codebase (and only if rewriting that codebase with a better language is not possible).

&#62; You’ll realize that Object Orientation is not the only way to architect software.<p>Actually, pretty much all the "good" C code I've seen is using some form of object orientation, for example using structs with function pointers, or information hiding through incomplete types and void pointers. I think the better observation is that you don't need much language support to do mostly-OOP.<p>That and a lot of people in those "other" languages are using language support for OOP as a bit of a mental crutch. (For example, many people working in Java or C# especially tend to write lots of indecipherable OO spaghetti.)

What you really want to say is not "learn C", but "learn computer architecture, algorithms and programming language semantics", C just happened to be the most convenient medium for this for a long time, but today there are perhaps better choices, like Go and I really hope C will finally go away one day, while people will still have to understand things like indirect addressing, hashing, pass-by-value vs. pass-by-reference an so on and so forth.

Please don't.<p>Learn Delphi, Free Pascal, Modula-2, Ada, Oberon(-2),... and see how it is possible to have down to the metal strong typed languages with native compilers.<p>Then understand that C and C++ ubiquity is an historical accident due to the way UNIX spread across the industry.

While I certainly agree that understanding the "how" will give you a better appreciation of the "what" and a more thorough understanding of the "why" behind many languages (I was one of the obnoxiously vocal detractors when American universities overwhelmingly moved from C/C++ to Java), I think this goes a little far:<p><i>When you internalize these lessons, your approach to programming will completely change.</i><p>You can know which parts of a language are heavier without knowing how they're implemented. Granted, this is certainly not the same, but in a practical sense it is certainly close. Your approach to programming will only "completely change" if you've been doing things with absolutely no understanding of the performance impact of the choices you make.<p>There are certainly people in that situation, but anyone who has had to do any profiling to find bottlenecks in code (which I would guess means most people who have been involved in professional development for more than a year or two) likely has at least an idea of which data and control structures are going to cause issues in languages they've used at length.<p>So yes, I agree that understanding what's going on is good... but not everyone has the time or inclination to delve into the depths of C, and there are other ways to come about a useful understanding of language internals (e.g. actually reading about a language's specific features rather than simply guessing at their implementation based on the assumption that they're written using standard C idioms).

A little off topic, but I think people need to realize that when someone says they're a programmer, all they mean is that they write code.<p>I know a lot of my friends (especially the ones in tech heavy cultures like Google, Facebook, Palantir, Dropbox) easily forget that when someone says "I'm a software engineer," they mean they write code. It doesn't mean they've gone through the same coursework, can reduce 3-SAT to everyday problems, form intricate algorithms, or have written their own memory allocator.<p>Keeping this in mind might make conversations go smoother.

I always felt shame that I knew C but didn't understand how the code works inside the CPU. Finally I got a grip of myself and got the book with the dragon on the cover, I managed to make my stupid C compiler. Turns out, it's not that hard, and doing that finally helped me understad stack and heap much better!<p>It also gave me the confidence to look at how bytecode based languages work -- turns out they're also not magic, and can be understood my mere mortals.<p>TLDR, assembly and compilers can be understood, and it'd fun too!

How does a musician without any formal CS education and a admitted lack of understanding of some very fundamental software things, such as pointers and memory, land a San Francisco dev job? I thought those jobs were in very high demand

Please please PUH-LEASE read "The C Programming Language" if you're going to learn C. It is THE most important programming book I've ever read. No other book comes close to concisely and elegantly describing a language.

I started programming for iOS via the same route, playing around with Objective-C in Xcode, but have since learned C. I have found that an understanding of C proves to be essential if I try to do anything reasonably complex (e.g. <a href="https://github.com/conradev/BlockTypeDescription" rel="nofollow">https://github.com/conradev/BlockTypeDescription</a>).<p>I have also found that another area in which newer developers fall short is understanding how Xcode works. Those familiar with interpreted languages do not have to compile their code. While they may understand the concept of 'modules', they don't know the difference between static and dynamic libraries, what 'linking' is, and how the compiler finds header files. Someone not knowledgeable of how this works will come upon innumerable headaches down the road, especially trying to integrate third party libraries.<p>I would suggest a supplementary post entitled "Learn How Xcode Works, You Cheater"

There exist proof and verification tools for C, like ACSL and Frama-C, [1] or LCL and Splint. [2,3] Not to mention the myriad of static and dynamic analysis tools. You can <i>prove</i> that a piece of C code does or doesn't contain certain bugs -- this is not the case for higher-level languages (except perhaps Haskell and ML). That is why C is used for highly sensitive projects like avionics.<p>I would say: learn C <i>and high-level languages</i>.<p>[1] <a href="http://frama-c.com/acsl.html" rel="nofollow">http://frama-c.com/acsl.html</a><p>[2] www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-74.pdf<p>[3] <a href="http://splint.org/" rel="nofollow">http://splint.org/</a>

I have to totally agree with this. I have almost completed Learn Python The Hard Way and it has been very good to me. I have been programming in many different languages while in school (I just graduated this May, lucky me...). I must say that this might be the most complete way that I have seen to learn a new language. I am definitely doing Learn C The Hard Way and I am definitely going to donate/pay for these materials. They are extremely beneficial to any programmer even if you know all of the information.

While I agree that all programmers should learn how computers and compilers work. Learning C would just be a mean to that end. You could easily replace "Learn C" with "Learn Assembly" in this post.<p>I think these type of posts reinforces the over-emphasis on languages, frameworks, and tools in general we have in this industry. People restrict themselves into camps of certain tools and then use that specific tool as a general purpose tool for all problems they face in a sort of nationalistic way. And then go on the internet and start arguing over which over-used hammer is better, so to speak. Now, what is worse is that newcomers to programming quickly adopt this attitude which makes it even harder for them to learn the right things.<p>The other day I made a trip to the Academy for Software engineering NYC[1] and it was a great experience watching kids learn how to program. They were using Python to learn. However, I was really disappointed when a few kids expressed interest in learning Foo language because someone told them that Foo was the best language ever! I told them that after learning how to compute, they can go on and learn all the languages they want to learn and even create their own.<p>[1]: <a href="http://www.afsenyc.org/" rel="nofollow">http://www.afsenyc.org/</a>

I "learned" C by writing a smal runit/daemontools replacement. Most of the work was learning the features I needed from libc: <a href="http://uggedal.github.io/going/going.c.html" rel="nofollow">http://uggedal.github.io/going/going.c.html</a>

I agree with the original poster. Learning C definitely allowed me to understand (and feel) the code from the inside. If you just use a Hashmap or Array without knowing how you'd do it in C, you're just playing with Lego pieces. (I also agree with his view on C++ but I won't poke that hornet nest)

Thanks for this, I'm going to work my way through <i>Learn C the Hard Way.</i> I started on Java, but now I use a lot of Ruby and Python, and both of those languages' original/main implementations are both written in C, so I want to learn how C works.

There is no doubt that learning c &#38; assembly language, help programmer to understand higher level languages better, even though they will not use c or assembly in their real work.

Somehow I thought that C is usually in the curriculum of any CS oriented university / college program, so most have at at least rudimentary knowledge of C.

Crap - is C a low-level language now? My view on the world is going to have to adjust.

Get the C t-shirt for the C hacker in you: <a href="http://teespring.com/c-faster" rel="nofollow">http://teespring.com/c-faster</a>

Very interesting thread. I moved to SV a year ago and my perspective on how modern programmers think has changed enormously.<p>As a background, I am a software engineer on route to being a cpu architect. My job is to understand how hardware works and what changes need to go into the instruction set to allow modern software work better. I have some thoughts to share.<p>I also think that a lot of folks in HN are true software engineers with little hardware background. So, most arguments simply gloss over why (or why not) use C.<p>Let us all be very clear. C is not a great language for app development. This comes from a person who has worked his entire life with C. I have no qualms in saying this.<p>C is primarily just an abstraction over assembly (not the same as machine). With this in mind, you can safely assume C to be a "stateful" language. By "stateful" I mean, each statement gets "executed" and the state of the CPU and memory changes. The fact that multiple assembly instructions can get produced per-line of C is what makes it better than lower languages.<p>That is all that is there in C. Everything else is an add-on. The standard library functions (strlen(), printf() etc.) are all essentially a few assembly instructions clubbed together.<p>Now, as it turns out, oop and other paradigms were created for the sole purpose of making it easy to program. In other words, we want to lower the barrier of entry into programming and have more programmers do things that they would normally never be able to do. We were ready to take a performance penalty with higher level languages so that more people can make useful stuff with a computer.<p>For example, oop was made to create the illusion that a program really is objects interacting with each other or functional execution. However, folks well versed with the computer know that oop is eventually executed sequentially.<p>The whole eco-system of web and app developers is able to thrive because they do not have to deal with 'nasty' (I personally find them amazing) issues of why things work the way they do. Let's just say that programming is becoming commoditized and the barrier to programming is made lower by them not having to deal with these issues. If we were still programming in C, most programmers would have dropped out of their CS classes when they were freshmen.<p>An analogy would be you don't need to understand the internals of a combustion engine to drive a car.<p>So, should everyone learn C? As someone who cares about expanding the powers of a computer, I do not think wasting resources on it is worthwhile. There are enough people maintaining C and using it for great purposes. Commodity programming (application level) should not involve C as far as possible. Cpus are fast enough to handle bloatware languages. I would personally prefer people thinking of newer languages/paradigms that would expand on what people can do with a computer.<p>As a programmer, you do not need to learn it. It is certainly helpful and I would definitely encourage folks to try to understand it, if you are curious. But no point wasting your time on it if all you are going to do is application level development.<p>Now, if you are working on something really deep and involved, the story changes completely. For example, folks working on router/switch programs, fast search engines, OS, devices, simulations (basically everything cool in my biased mind) need to understand it.<p>An analogy is that an you do not need to understand nitty-gritty details about engines unless you are building something in the range of a Ferrari.<p>Just my thoughts.

&#62; You’ll realize that Object Orientation is not the only way to architect software.<p>I don't think C is really the way to learn this lesson - try a functional programming language to really get a feel for an entirely different programming paradigm.

Film at 11.