15 ms·

Learn C

286 points by wx196 13y ago

jchonphoenix 13y ago
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. 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. Keeping this in mind might make conversations go smoother.
- kunai 13y ago
  http://xkcd.com/378/ http://xkcd.com/378/
- doktrin 13y ago
  > when someone says they're a programmer, all they mean is that they write code. How is this an inaccurate or misleading statement? If they write code for a living, they're programmers. > A little off topic IMO that's an understatement.
  - cthackers 13y ago
    There is a difference. The difference between someone who works as a programmer, who takes it just as a job but of course can be extremely good at it - just like anything else you practice a lot; and someone who is a programmer. They are lexically the same but they mean different things. The last one, beside working (or not) as a programmer, does it for the art of it. Who not necessarily learns or does something (ships) because it's needed or it provides anything else beside the joy and fulfilment of learning and understanding it. For example, at work, when you want to stop programming you open your own personal open source project and relax for an hour with it. Then you go home after 8 hours of programming and start up your IDE and carry on with your art that may or may not ever see the light of day and it makes no difference.
    - doktrin 13y ago
      That's hazy territory. While I understand what you're trying to get across, there's really no point adding layers of hidden meaning and subjectivity to the term "programmer". (non-software) engineers, lawyers, graphic designers, accountants, chemists, doctors define themselves by occupation and not some subjective non-metric of passion. Why exactly should programming be different? I'm not arguing that programmers shouldn't be passionate about their work, or work on side projects. However, there's really no point in prevaricating over what a "Real Programmer"(tm) is, beyond the very simple working definition we have.
      - cthackers 13y ago
        Because we're talking about programming here. If we were talking about music for example, the same will apply. There are singers and there are artists and there is a clear difference in a song well made and a commercial song. Even if the last one makes you more money. But for programmers there's just that one term to use. So the need to point the hidden meanings.
        doktrin 13y ago
        There are no "hidden meanings". You're making them up. edit : Words, like functions, work best when their meaning is simple and clear. Like functions, there's nothing wrong with combining them (e.g. "good programmer", "passionate programmer", "programming craftsman", "software composer"), but shoehorning multiple definitions into a single word will just inevitably lead to confusion.
- jcrites 13y ago
  There is a lot more to software engineering than writing code. As I see it, proficiency in software engineering includes topics such as: 1. cost efficacy 2. availability, reliability, and scalability 3. administration (system administration); operations and support; troubleshooting & crisis management (this and #2 are their own sub-field: site reliability engineering / devops) 4. security: risk analysis, threat modeling, cryptography, access control, vulnerability management, incident response (another sub-field) 5. computing science: algorithms, data structures 6. networks, distributed systems, load balancing 7. programming: languages, compilers, VMs, frameworks 8. quality assurance, testing 9. application architecture 10. data storage: databases, relational and non-relational, caching, transactions, replication, locality 11. facilities, data centers (power distribution, cooling - though that's getting more into system engineering) 12. product design, customer experience, accessibility, human factors 13. project management I think of programming as the art of writing code. Engineering is the act of creating reliable, controllable systems -- systems that achieve their technical goals and business goals in a steady, reproducible way. Engineering is the act of balancing tradeoffs scientifically and ensuring that quality goals are effectively met. You might call any autodidact coder a programmer. College students can be adept programmers. However, writing code is just one part of being a software engineer. I would expect senior and above level software engineers to have experience in most or all of the topics above, and I'm sure there are more that deserve to be on the list. Engineering in the software field isn't /always/ about building super-reliable things. That is one factor that I think differentiates it from other engineering fields. Engineering in the real, physical space has safety implications that typically require a high level of rigor at minimum. If a bridge fails or a building collapses, that's catastrophic. Physical products are only useful if engineered to a high level of quality. However, software is useful across a wider spectrum of reliability: if a back-office web app used by the recruiting team has to come down for maintenance for 2 hours on Sunday, that may not be a showstopper. Consequently, part of software engineering is understanding what level of robustness is needed to meet business goals, and building to it appropriately, with appropriate costs, and understanding the properties of the built system. Controlling the level of reliability is what makes it engineering. To be fair, I cannot account for what someone else means when they say they're a software engineer. But this is what I mean, and I consider the field to cover a number of topics and subjects beyond programming.
- effbott 13y ago
  http://en.wikipedia.org/wiki/No_true_Scotsman http://en.wikipedia.org/wiki/No_true_Scotsman
kunai 13y ago
You'll learn to feel every line of code you write This is exactly how I felt when I started writing C. 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&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. 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. 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 feel yourself driving, and when you step back into the Mercedes, you feel numbed. It's the same with C.
- sigkill 13y ago
  A small part of C was beaten into us for 2 years at the 11th and 12th grade. Today (I'm not a CS guy by the way), even when I write programs in python or any high level language I have this nagging feeling of 'loss of control' and that the code is not efficient enough. I know this is wrong but I can't help this feeling when now things are handed to you as compared to flipping every figurative bit in C.
  - pointyhats 13y ago
    It is right not wrong. Being decoupled from the machine by several layers of abstraction means you're just rearranging the furniture rather than whittling it out of wood. I hate rearranging the furniture; it gives no satisfaction. Satisfaction is a big part of quality in your life.
andrewvc 13y ago
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. 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.
- mbel 13y ago
  I totally agree; actually a small, incomplete Scheme interpreter (which may be used to develop a lisp compiler later on) can be easily created in few hours (depending on used language) [0], without any prior experience. It's surely not as deep learning experience as building a compiler, but I think it's still worthwhile. [0] http://norvig.com/lispy.html http://norvig.com/lispy.html
  - irahul 13y ago
    A more complete interpreter: http://norvig.com/lispy2.html http://norvig.com/lispy2.html
  - z3phyr 13y ago
    http://en.m.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours http://en.m.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48... Write yourself scheme in 48 hours (with haskell). Great learning experiance!!
- fdr_cs 13y ago
conradev 13y ago
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. https://github.com/conradev/BlockTypeDescription https://github.com/conradev/BlockTypeDescription). 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. I would suggest a supplementary post entitled "Learn How Xcode Works, You Cheater"
- hbridges 13y ago
  Might could do that! Actually one of the biggest mysteries to me for a while was how header files worked, how the compiler finds symbols, build dependencies, linking libs, etc. Having to mess around with Makefiles helps you digest those things, but then Xcode treats them in an entirely different way. #include is a complex beast
  - tjdetwiler 13y ago
    #include is actually a very simple beast, once you realize that it's much easier to digest.
mimog 13y ago
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
- zeeshanl 13y ago
  As a person with a masters in music, a bachelor in film, and now programming for a living, I def. believe that having a persistant interest in learning about those "fundamental software concepts" is what makes such a gig achievable, especially if you keep doing the extra work in your spare time (like taking Dan Grossman's unbelievable Programming Languages class or going through Zed's LCTHW).
  - mimog 13y ago
    Given that you have a masters degree in music I would wager it would take me a very long time to get to your level in playing, writing and understanding music. It's doable of course, but I would have a lot of learning and work ahead of me. I think the same would apply to you catching up to someone having a masters degree in computer science or related fields.
    - zeeshanl 13y ago
      I don't have a high opinion of my musical abilities :), but I agree that catching-up is both a doable and daunting process. But, finding niches of interest to focus on usually helps, as it does when crafting really good songs in a specific style, one that matches your musical abilities and understanding. You may not have the chops, but you can still create amazing work. With programming, I have the issue of wanting to catch up on everything and do side-projects (eventually, I'll run through this class => http://faculty.cs.byu.edu/~jay/courses/2012/fall/330/course/gc.html http://faculty.cs.byu.edu/~jay/courses/2012/fall/330/course/...), but I have found success in trying to pick-up things in conjunction with a task at hand. If I have to build a web service, I'll start that research simultaneously. Starting IOS work... then spend time with C, understand Objective-C's runtime, read about the history (and play around with Smalltalk). This piece-meal approach seems to make the jump more "doable" in my opinion. I think that people without a CS degree can obtain a good, challenging gig if they have a good niche to school themselves in, and of course, pick-up the gaps from the people they work along with who have that background/knowledge.
betterunix 13y ago
We need less 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. 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).
- hbridges 13y ago
  My point is there are fundamental computing concepts that you can pick up by learning C. In a world of high-level, low-LOC languages you can get by without learning those concepts, but it serves your and the ecosystem's best interest to learn them.
  - betterunix 13y ago
    I think the disagreement we have may stem from our notions of what constitutes "fundamental computing concepts." I rank the lambda calculus much higher than C or assembly language when it comes to that. I would say that knowing your data structures and how to analyze algorithms asymptotically is vastly more important than knowing how code is being executed at a low level. Even for the cases where low-level code must be written, I would say we need people who know assembly language and compiler theory more than we need people who know C. There is no particularly good reason for C to be anywhere in the software stack; you can bootstrap Lisp, ML, etc. without writing any C code. We need people who know how to write optimizing compilers; those people do not need to know C, nor should they waste their time with C. Really, the most important computing concept people need to learn is abstraction. Understanding that a program can be executed as machine code, or an interpreted IR, or just interpreting an AST, and that code can itself be used to construct higher level abstractions is more important than learning any particular language.
    - com2kid 13y ago
losethos 13y ago
I made Holy C, a dialect that is incompatible. I made a compiler. I gradually added more features. It has postfix typecasting. It has better operator precedence rules. God says... writings authority fathers' dir offer wondrous enquire collectively easeful edify Passion lengthened smart filename GUTENBERG-TM command-line Shakespeare Armenia delights ho_ho_ho grievously adorning diversely fouls natural If_had_my_druthers admonish respect chewing Greece stretch bin bloom sweetness sentences see' thirsts Small fees THE aquatic sleepest solstices mimic sharper search needeth I'm_bored indignant toward play sign constituted seldomness woke regenerated aforetime Panama gathered Awake Euodius tearful conveying touchedst intently derision subduing partaker excited goods nourish observeth ranked emptinesses gainsayer so_he_sess readers' Him attributing interpret disease gain DISCLAIMER confirmed questioning fig-tree said consolations licensed bickering pieces thinks chest Neptune what_a_nightmare pilgrimage skies _ pursues correct dissolution tree manifoldness falling nourishments small forceth patched C eluding celibacy multitude Sudden shunning MS whirlings If rejoicest countenance pertained doting approveth Vatican_City seductive middle shared window curing ascend inhabitants consumest useful http://www.templeos.org/Wb/Doc/HolyC.html http://www.templeos.org/Wb/Doc/HolyC.html
wmt 13y ago
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! 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. TLDR, assembly and compilers can be understood, and it'd fun too!
danso 13y ago
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): (Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming (Kindle Location 6269). Kindle Edition: http://www.amazon.com/Coders-Work-Reflections-Craft-Programming/dp/1430219483 http://www.amazon.com/Coders-Work-Reflections-Craft-Programm... ) Seibel: When do you think was the last time that you programmed? 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.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? 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.
- habitue 13y ago
  I think she might have given up on programming a bit prematurely. The pendulum has obviously swung completely the other way with high level languages like Haskell pushing forward compiler optimization, and JIT VMs pushing forward in other directions. It's actually an exciting time for "smart compilers".
vbv 13y ago
Get the C t-shirt for the C hacker in you: http://teespring.com/c-faster http://teespring.com/c-faster
obviouslygreen 13y ago
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: When you internalize these lessons, your approach to programming will completely change. 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. 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. 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).
stiff 13y ago
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.
asveikau 13y ago
> You’ll realize that Object Orientation is not the only way to architect software. 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. 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.)
- btilly 13y ago
  People who use the preprocessor heavily tend to use a fairly non-OO design. See http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html for an interesting example of a design technique enabled by that. I also note that said technique is problematic in practice not because it isn't good - it is - but because it causes people to suffer a brain freeze.
  - asveikau 13y ago
    I tend to see these as orthogonal. What does a macro do but generate more code? So shouldn't the use of macros be reducible to ordinary code? That, and you can still employ this stuff at the micro level and your chatter between compilation units or library boundaries can still be OO.
    - btilly 13y ago
      In my experience, people who like to use the preprocessor come up with very non-OO abstractions. Similarly people who program heavily using templates in C++ tend not to use a lot of the OO features there either. I may be more aware of this than you because my design sensibilities by nature are not particularly OO. This is not to say that I can't produce and understand OO designs. I both can and do, particularly if I have to cooperate with people who expect that. But given the choice, I'm more likely to head in a different direction. (A dictionary full of closures can be surprisingly useful...)
pjmlp 13y ago
Please don't. 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. Then understand that C and C++ ubiquity is an historical accident due to the way UNIX spread across the industry.
- sliverstorm 13y ago
  Accident? C did exactly what it was designed to do; allow UNIX to spread to other architectures.
  - pjmlp 13y ago
    Any high level language would do it in a time and age where most OS were still 100% coded in Assembly. Lets say UNIX used PL/I or Algol 68, the article would be called "Learn PL/I" or "Learn Algol 68".
    - sliverstorm 13y ago
      I can't say you couldn't have written UNIX in Algol 68, but C was very specifically developed by K&R for building the underpinnings of UNIX. They didn't just "pick" C out of a pool of available languages- C was made for UNIX. (This is probably a gross oversimplification- please don't hang me out to dry for it- but it summarizes my understanding of the origins of C)
      - pjmlp 13y ago
        C was made with UNIX, not for, mostly because the authors did not like to use other available languages. There is hardly any feature in the language that makes it better than other higher level languages for systems programming. Please note that I am older than C, for me higher level language is anything higher than Assembly.
        sliverstorm 13y ago
        I suppose I'm descending to semantics and quibbling over meaningless details at this point, but I was just taking issue with the idea that C wound up in its current position on accident. It was not by chance that C makes up the underpinnings of UNIX, nor did (to my knowledge) the spread of UNIX have much to do with chance. I don't mean to contend there are no other languages that could have been used.
peterkelly 13y ago
Film at 11.
uggedal 13y ago
I "learned" C by writing a smal runit/daemontools replacement. Most of the work was learning the features I needed from libc: http://uggedal.github.io/going/going.c.html http://uggedal.github.io/going/going.c.html
bmoresbest55 13y ago
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.
- zedshaw 13y ago
  Thanks! Glad you liked my book. Any criticisms for improvements?
rmrfrmrf 13y ago
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.
- gnuvince 13y ago
  If K&R is the most important programming you've read, you have many more books to read methinks :)
amasad 13y ago
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. 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. 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. [1]: http://www.afsenyc.org/ http://www.afsenyc.org/
kuchaguangjie 13y ago
There is no doubt that learning c & assembly language, help programmer to understand higher level languages better, even though they will not use c or assembly in their real work.
sengstrom 13y ago
Crap - is C a low-level language now? My view on the world is going to have to adjust.
smegel 13y ago
> You’ll realize that Object Orientation is not the only way to architect software. 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.
shmerl 13y ago
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.
NTDF 13y ago
Very interesting thread. I moved to SV a year ago and my perspective on how modern programmers think has changed enormously. 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. 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. 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. 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. 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. 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. 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. 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. An analogy would be you don't need to understand the internals of a combustion engine to drive a car. 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. 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. 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. 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. Just my thoughts.
kyllo 13y ago
Thanks for this, I'm going to work my way through Learn C the Hard Way. 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.
ergest 13y ago
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)
peripetylabs 13y ago
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 prove 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. I would say: learn C and high-level languages. [1] http://frama-c.com/acsl.html http://frama-c.com/acsl.html [2] www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-74.pdf [3] http://splint.org/ http://splint.org/

286 points by wx196 13y ago

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. 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. Keeping this in mind might make conversations go smoother.

kunai 13y ago
http://xkcd.com/378/ http://xkcd.com/378/
doktrin 13y ago
> when someone says they're a programmer, all they mean is that they write code. How is this an inaccurate or misleading statement? If they write code for a living, they're programmers. > A little off topic IMO that's an understatement.
- cthackers 13y ago
  There is a difference. The difference between someone who works as a programmer, who takes it just as a job but of course can be extremely good at it - just like anything else you practice a lot; and someone who is a programmer. They are lexically the same but they mean different things. The last one, beside working (or not) as a programmer, does it for the art of it. Who not necessarily learns or does something (ships) because it's needed or it provides anything else beside the joy and fulfilment of learning and understanding it. For example, at work, when you want to stop programming you open your own personal open source project and relax for an hour with it. Then you go home after 8 hours of programming and start up your IDE and carry on with your art that may or may not ever see the light of day and it makes no difference.
  - doktrin 13y ago
    That's hazy territory. While I understand what you're trying to get across, there's really no point adding layers of hidden meaning and subjectivity to the term "programmer". (non-software) engineers, lawyers, graphic designers, accountants, chemists, doctors define themselves by occupation and not some subjective non-metric of passion. Why exactly should programming be different? I'm not arguing that programmers shouldn't be passionate about their work, or work on side projects. However, there's really no point in prevaricating over what a "Real Programmer"(tm) is, beyond the very simple working definition we have.
    - cthackers 13y ago
      Because we're talking about programming here. If we were talking about music for example, the same will apply. There are singers and there are artists and there is a clear difference in a song well made and a commercial song. Even if the last one makes you more money. But for programmers there's just that one term to use. So the need to point the hidden meanings.
      - doktrin 13y ago
        There are no "hidden meanings". You're making them up. edit : Words, like functions, work best when their meaning is simple and clear. Like functions, there's nothing wrong with combining them (e.g. "good programmer", "passionate programmer", "programming craftsman", "software composer"), but shoehorning multiple definitions into a single word will just inevitably lead to confusion.
jcrites 13y ago
There is a lot more to software engineering than writing code. As I see it, proficiency in software engineering includes topics such as: 1. cost efficacy 2. availability, reliability, and scalability 3. administration (system administration); operations and support; troubleshooting & crisis management (this and #2 are their own sub-field: site reliability engineering / devops) 4. security: risk analysis, threat modeling, cryptography, access control, vulnerability management, incident response (another sub-field) 5. computing science: algorithms, data structures 6. networks, distributed systems, load balancing 7. programming: languages, compilers, VMs, frameworks 8. quality assurance, testing 9. application architecture 10. data storage: databases, relational and non-relational, caching, transactions, replication, locality 11. facilities, data centers (power distribution, cooling - though that's getting more into system engineering) 12. product design, customer experience, accessibility, human factors 13. project management I think of programming as the art of writing code. Engineering is the act of creating reliable, controllable systems -- systems that achieve their technical goals and business goals in a steady, reproducible way. Engineering is the act of balancing tradeoffs scientifically and ensuring that quality goals are effectively met. You might call any autodidact coder a programmer. College students can be adept programmers. However, writing code is just one part of being a software engineer. I would expect senior and above level software engineers to have experience in most or all of the topics above, and I'm sure there are more that deserve to be on the list. Engineering in the software field isn't /always/ about building super-reliable things. That is one factor that I think differentiates it from other engineering fields. Engineering in the real, physical space has safety implications that typically require a high level of rigor at minimum. If a bridge fails or a building collapses, that's catastrophic. Physical products are only useful if engineered to a high level of quality. However, software is useful across a wider spectrum of reliability: if a back-office web app used by the recruiting team has to come down for maintenance for 2 hours on Sunday, that may not be a showstopper. Consequently, part of software engineering is understanding what level of robustness is needed to meet business goals, and building to it appropriately, with appropriate costs, and understanding the properties of the built system. Controlling the level of reliability is what makes it engineering. To be fair, I cannot account for what someone else means when they say they're a software engineer. But this is what I mean, and I consider the field to cover a number of topics and subjects beyond programming.
effbott 13y ago
http://en.wikipedia.org/wiki/No_true_Scotsman http://en.wikipedia.org/wiki/No_true_Scotsman

kunai 13y ago

You'll learn to feel every line of code you write This is exactly how I felt when I started writing C. 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&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. 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. 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 feel yourself driving, and when you step back into the Mercedes, you feel numbed. It's the same with C.

sigkill 13y ago
A small part of C was beaten into us for 2 years at the 11th and 12th grade. Today (I'm not a CS guy by the way), even when I write programs in python or any high level language I have this nagging feeling of 'loss of control' and that the code is not efficient enough. I know this is wrong but I can't help this feeling when now things are handed to you as compared to flipping every figurative bit in C.
- pointyhats 13y ago
  It is right not wrong. Being decoupled from the machine by several layers of abstraction means you're just rearranging the furniture rather than whittling it out of wood. I hate rearranging the furniture; it gives no satisfaction. Satisfaction is a big part of quality in your life.

andrewvc 13y ago

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. 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.

mbel 13y ago
I totally agree; actually a small, incomplete Scheme interpreter (which may be used to develop a lisp compiler later on) can be easily created in few hours (depending on used language) [0], without any prior experience. It's surely not as deep learning experience as building a compiler, but I think it's still worthwhile. [0] http://norvig.com/lispy.html http://norvig.com/lispy.html
- irahul 13y ago
  A more complete interpreter: http://norvig.com/lispy2.html http://norvig.com/lispy2.html
- z3phyr 13y ago
  http://en.m.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours http://en.m.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48... Write yourself scheme in 48 hours (with haskell). Great learning experiance!!
fdr_cs 13y ago

conradev 13y ago

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. https://github.com/conradev/BlockTypeDescription https://github.com/conradev/BlockTypeDescription). 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. I would suggest a supplementary post entitled "Learn How Xcode Works, You Cheater"

hbridges 13y ago
Might could do that! Actually one of the biggest mysteries to me for a while was how header files worked, how the compiler finds symbols, build dependencies, linking libs, etc. Having to mess around with Makefiles helps you digest those things, but then Xcode treats them in an entirely different way. #include is a complex beast
- tjdetwiler 13y ago
  #include is actually a very simple beast, once you realize that it's much easier to digest.

mimog 13y ago

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

zeeshanl 13y ago
As a person with a masters in music, a bachelor in film, and now programming for a living, I def. believe that having a persistant interest in learning about those "fundamental software concepts" is what makes such a gig achievable, especially if you keep doing the extra work in your spare time (like taking Dan Grossman's unbelievable Programming Languages class or going through Zed's LCTHW).
- mimog 13y ago
  Given that you have a masters degree in music I would wager it would take me a very long time to get to your level in playing, writing and understanding music. It's doable of course, but I would have a lot of learning and work ahead of me. I think the same would apply to you catching up to someone having a masters degree in computer science or related fields.
  - zeeshanl 13y ago
    I don't have a high opinion of my musical abilities :), but I agree that catching-up is both a doable and daunting process. But, finding niches of interest to focus on usually helps, as it does when crafting really good songs in a specific style, one that matches your musical abilities and understanding. You may not have the chops, but you can still create amazing work. With programming, I have the issue of wanting to catch up on everything and do side-projects (eventually, I'll run through this class => http://faculty.cs.byu.edu/~jay/courses/2012/fall/330/course/gc.html http://faculty.cs.byu.edu/~jay/courses/2012/fall/330/course/...), but I have found success in trying to pick-up things in conjunction with a task at hand. If I have to build a web service, I'll start that research simultaneously. Starting IOS work... then spend time with C, understand Objective-C's runtime, read about the history (and play around with Smalltalk). This piece-meal approach seems to make the jump more "doable" in my opinion. I think that people without a CS degree can obtain a good, challenging gig if they have a good niche to school themselves in, and of course, pick-up the gaps from the people they work along with who have that background/knowledge.

betterunix 13y ago

We need less 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. 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).

hbridges 13y ago
My point is there are fundamental computing concepts that you can pick up by learning C. In a world of high-level, low-LOC languages you can get by without learning those concepts, but it serves your and the ecosystem's best interest to learn them.
- betterunix 13y ago
  I think the disagreement we have may stem from our notions of what constitutes "fundamental computing concepts." I rank the lambda calculus much higher than C or assembly language when it comes to that. I would say that knowing your data structures and how to analyze algorithms asymptotically is vastly more important than knowing how code is being executed at a low level. Even for the cases where low-level code must be written, I would say we need people who know assembly language and compiler theory more than we need people who know C. There is no particularly good reason for C to be anywhere in the software stack; you can bootstrap Lisp, ML, etc. without writing any C code. We need people who know how to write optimizing compilers; those people do not need to know C, nor should they waste their time with C. Really, the most important computing concept people need to learn is abstraction. Understanding that a program can be executed as machine code, or an interpreted IR, or just interpreting an AST, and that code can itself be used to construct higher level abstractions is more important than learning any particular language.
  - com2kid 13y ago

losethos 13y ago

I made Holy C, a dialect that is incompatible. I made a compiler. I gradually added more features. It has postfix typecasting. It has better operator precedence rules. God says... writings authority fathers' dir offer wondrous enquire collectively easeful edify Passion lengthened smart filename GUTENBERG-TM command-line Shakespeare Armenia delights ho_ho_ho grievously adorning diversely fouls natural If_had_my_druthers admonish respect chewing Greece stretch bin bloom sweetness sentences see' thirsts Small fees THE aquatic sleepest solstices mimic sharper search needeth I'm_bored indignant toward play sign constituted seldomness woke regenerated aforetime Panama gathered Awake Euodius tearful conveying touchedst intently derision subduing partaker excited goods nourish observeth ranked emptinesses gainsayer so_he_sess readers' Him attributing interpret disease gain DISCLAIMER confirmed questioning fig-tree said consolations licensed bickering pieces thinks chest Neptune what_a_nightmare pilgrimage skies _ pursues correct dissolution tree manifoldness falling nourishments small forceth patched C eluding celibacy multitude Sudden shunning MS whirlings If rejoicest countenance pertained doting approveth Vatican_City seductive middle shared window curing ascend inhabitants consumest useful http://www.templeos.org/Wb/Doc/HolyC.html http://www.templeos.org/Wb/Doc/HolyC.html

wmt 13y ago

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! 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. TLDR, assembly and compilers can be understood, and it'd fun too!

danso 13y ago

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): (Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming (Kindle Location 6269). Kindle Edition: http://www.amazon.com/Coders-Work-Reflections-Craft-Programming/dp/1430219483 http://www.amazon.com/Coders-Work-Reflections-Craft-Programm... ) Seibel: When do you think was the last time that you programmed? 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.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? 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.

habitue 13y ago
I think she might have given up on programming a bit prematurely. The pendulum has obviously swung completely the other way with high level languages like Haskell pushing forward compiler optimization, and JIT VMs pushing forward in other directions. It's actually an exciting time for "smart compilers".

vbv 13y ago

Get the C t-shirt for the C hacker in you: http://teespring.com/c-faster http://teespring.com/c-faster

obviouslygreen 13y ago

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: When you internalize these lessons, your approach to programming will completely change. 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. 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. 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).

stiff 13y ago

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.

asveikau 13y ago

> You’ll realize that Object Orientation is not the only way to architect software. 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. 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.)

btilly 13y ago
People who use the preprocessor heavily tend to use a fairly non-OO design. See http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html for an interesting example of a design technique enabled by that. I also note that said technique is problematic in practice not because it isn't good - it is - but because it causes people to suffer a brain freeze.
- asveikau 13y ago
  I tend to see these as orthogonal. What does a macro do but generate more code? So shouldn't the use of macros be reducible to ordinary code? That, and you can still employ this stuff at the micro level and your chatter between compilation units or library boundaries can still be OO.
  - btilly 13y ago
    In my experience, people who like to use the preprocessor come up with very non-OO abstractions. Similarly people who program heavily using templates in C++ tend not to use a lot of the OO features there either. I may be more aware of this than you because my design sensibilities by nature are not particularly OO. This is not to say that I can't produce and understand OO designs. I both can and do, particularly if I have to cooperate with people who expect that. But given the choice, I'm more likely to head in a different direction. (A dictionary full of closures can be surprisingly useful...)

pjmlp 13y ago

Please don't. 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. Then understand that C and C++ ubiquity is an historical accident due to the way UNIX spread across the industry.

sliverstorm 13y ago
Accident? C did exactly what it was designed to do; allow UNIX to spread to other architectures.
- pjmlp 13y ago
  Any high level language would do it in a time and age where most OS were still 100% coded in Assembly. Lets say UNIX used PL/I or Algol 68, the article would be called "Learn PL/I" or "Learn Algol 68".
  - sliverstorm 13y ago
    I can't say you couldn't have written UNIX in Algol 68, but C was very specifically developed by K&R for building the underpinnings of UNIX. They didn't just "pick" C out of a pool of available languages- C was made for UNIX. (This is probably a gross oversimplification- please don't hang me out to dry for it- but it summarizes my understanding of the origins of C)
    - pjmlp 13y ago
      C was made with UNIX, not for, mostly because the authors did not like to use other available languages. There is hardly any feature in the language that makes it better than other higher level languages for systems programming. Please note that I am older than C, for me higher level language is anything higher than Assembly.
      - sliverstorm 13y ago
        I suppose I'm descending to semantics and quibbling over meaningless details at this point, but I was just taking issue with the idea that C wound up in its current position on accident. It was not by chance that C makes up the underpinnings of UNIX, nor did (to my knowledge) the spread of UNIX have much to do with chance. I don't mean to contend there are no other languages that could have been used.

peterkelly 13y ago

Film at 11.

uggedal 13y ago

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

bmoresbest55 13y ago

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.

zedshaw 13y ago
Thanks! Glad you liked my book. Any criticisms for improvements?

rmrfrmrf 13y ago

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.

gnuvince 13y ago
If K&R is the most important programming you've read, you have many more books to read methinks :)

amasad 13y ago

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. 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. 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. [1]: http://www.afsenyc.org/ http://www.afsenyc.org/

kuchaguangjie 13y ago

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

sengstrom 13y ago

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

smegel 13y ago

> You’ll realize that Object Orientation is not the only way to architect software. 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.

shmerl 13y ago

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.

NTDF 13y ago

Very interesting thread. I moved to SV a year ago and my perspective on how modern programmers think has changed enormously. 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. 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. 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. 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. 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. 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. 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. 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. An analogy would be you don't need to understand the internals of a combustion engine to drive a car. 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. 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. 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. 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. Just my thoughts.

kyllo 13y ago

Thanks for this, I'm going to work my way through Learn C the Hard Way. 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.

ergest 13y ago

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)

peripetylabs 13y ago

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 prove 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. I would say: learn C and high-level languages. [1] http://frama-c.com/acsl.html http://frama-c.com/acsl.html [2] www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-74.pdf [3] http://splint.org/ http://splint.org/