Hacker News Reader

Comment by rhuber | Hacker News Reader

Every aspiring programmer should learn C. They should also learn multiple dialects of ASM. Learning these things helps you better understand how computers fundamentally work, and knowing how computers work pushes you to write better code in any language. Ignoring how computers organize data can lead to inefficient code in any language.

That said, if you are writing something new, you should carefully consider whether C is the best choice before using it. If you are working within a nearly-impossible-to-replace + enormous codebase (such as the Linux kernel), it is the only option. If your project's #1 goal is performance above all else, and you are a seasoned or aspiring expert, perhaps C is the best choice. The majority of people writing software do not fall into either of these categories.

View on HN

I feel like the length of the list of things "every programmer should know" is approaching infinity.

From my experience working with people, one can be an excellent programmer knowing just one language, whether it is C#, Ruby, or Java. On the other hand, I have met (too many) people who "knew" a lot but who were quite bad at putting that knowledge into practice.

I feel like the list of things "every programmer should know" tends to include "all the things I know,"in which case you may be right.

I'm not sure I agree. Maybe the list of things presented by bloggers as things every programmer should know, but C would not be a new addition to such a list in any case.

Neither C++ or Rust has any characteristic that would make it slower than C. It's all up to what is your existing codebase, and what kind of experts you have. Also, both languages can mix with C. For example, the Linux Kernel could also accept C++ code easily if they wanted, but it's a conscious decision not to do so. So, yeah, C is not the only option.

Even in an existing codebase written in C it may be possible to avoid it, if you are able to choose whether to introduce a new language for some components.

...if you are able to choose whether to introduce a new language for some components... Well, there are complexity, readability and maintenance costs associated with introducing any new dependencies into a project. And (in my opinion) these costs go in the following order, from small to high:

1. header-only library 2. compiled library 3. compiled library with type framework 4. framework 5. meta-programming framework 6. custom meta-programming framework 7. domain specific language 8. custom domain specific language 9. generic programming language 10. custom generic programming language

As a side note, increase in complexity also might increase job security of a developer. If you are after it, design your own programming language and try to deliver every project implemented in it :) Should your projects be in high demand, your skills will be in high demand as well!

Yeah, there's obviously a cost involved. It's not something I'd want to do more than once within a project.

Reply on news.ycombinator.com