10 ms·

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; wri

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
    > There is no particularly good reason for C to be anywhere in the software stack; Really? Not anywhere? Who is handling your hardware interrupts? How is your keyboard and mouse input being handled? What about your video card drivers? Now I will grant that you can bootstrap an initial run time in assembly and place your favorite high level language4 on top of that, if you add extensions to your favorite language to better interact with HW you can do everything in a higher level language, but as it stands, LISP doesn't have built in support for doing a DMA copy from memory buffer to a USB port. My question then becomes, why the heck bootstrap in ASM rather than C?
    - austinz 13y ago
      Agreed; OS kernels and firmware for embedded systems all require low-level access to hardware in a way that high-level desktop applications do not. Being able to easily reason about how C is going to use resources and be compiled down to machine code for the architecture you are using can sometimes be an important asset.
      - tracker1 13y ago
        I think that the point is that even if you accept that the kernel level code and device drivers are all in C, from there, there's less and less benefit to doing userland code in C from there... you could use Lisp, Erlang, Scheme or a number of other languages for userland and service oriented code. Although I really don't care for Unity, or Windows 8's UI's I do appreciate some of the directions they are going in terms of being able to create applications that are more abstracted in nature. I personally happen to like higher level languages/environments, and modern hardware has been able to handle them very well for years. I do think that certain patterns and practices that people have followed need to be re-thought for parallelism, and that a thread/process per request in service oriented architectures has now been a bottleneck... but there are techniques, languages and platforms that can take us much farther without digging into a low-level platform language like C. I agree that knowing C is helpful, so is knowing assembly... that doesn't mean even a small fraction of developers should be working with them on a daily basis. Most code is one-off line of business application code and related services. It doesn't need sheer performance, it needs to be done and in production sooner... the next thing needs to get done. You can't create software as quickly in C/Assembly as you can in Java/C# (or Python, Ruby, NodeJS).
fdr_cs 13y ago
its not about writing new code in C. Its about learning how you prefered language is implemented. Learn your tools , its really important.
nemo1618 13y ago
I wouldn't say this article is recommending that you go out and program in C full-time. Many people have learned Lisp (and are better programmers for it), but few actually use it at their day job.
kmm 13y ago
Was there any study done to the (un)reliability of C? I know for a fact practically every piece software I use is programmed in either C or C++. The sole exceptions are Anki and Gentoo's portage system, both Python. And I'm pretty sure the reason portage is so extremely slow is because it is in Python (I've checked, it's not I/O-bound). And Anki is some very unreliable software. In fact, give me a single big desktop software project made with a language that is not C or C++.
- betterunix 13y ago
  "I know for a fact practically every piece software I use is programmed in either C or C++." How confident are you that that software will work as expected? How much are you willing to bet? The fact that a language is popular does not prove that the language is good, nor that it should be used, nor that it is not causing us problems. Just the other day on HN, there was an article about a massive number of vulnerabilities in X11 applications -- all resulting from problems that you have in C and C++ but not in higher-level languages. Entire classes of bugs that are common problems in C are just not an issue in other languages. Sure, it is possible to write unreliable code in high-level languages. It is just a lot easier to write unreliable C code, and C programmers are much more likely to do so (even those with years of experience).
  - Jabbles 13y ago
    "There are only two kinds of languages: the ones people complain about and the ones nobody uses" Bjarne Stroustrup http://www.stroustrup.com/bs_faq.html#really-say-that http://www.stroustrup.com/bs_faq.html#really-say-that Of course, that just dismisses the criticism of the language. But to say that it "should [not] be used" ignores the current landscape of engineers, employers and problems.
    - pjscott 13y ago
      That quote is always annoying, because it applies equally well to all criticisms of any programming language in active use, but not all criticisms are created equal. A useful heuristic would actually help distinguish between reasonable criticism and inevitable kvetching.
trimbo 13y ago
> We already have a problem with a massive, unreliable, insecure ecosystem of legacy C code A ton of the world's software with the highest reliability requirements is written in C and C++. Nuclear power plants? Yes. [1] Joint Strike Fighter? Yes. [2] Mars rover? Yes. [3] Your Tesla? Yes [4] US telephone systems. Stock exchanges. Bloomberg. Your cell phone OS (incl. many years before smartphones). The list goes on and on. C and C++ are the most general and well-supported languages we have. They can solve problems on any architecture with a good tradeoff between efficiency and generality (over assembly) and predictable performance. Reliability and security requirements are up to the developer to impose on any language (see: the github PHP SQL injection search). C is not, in itself, a problem towards these goals and those who build upon C are always improving it [5]. [1] - http://www.nrc.gov/reading-rm/doc-collections/nuregs/contract/cr6463/ http://www.nrc.gov/reading-rm/doc-collections/nuregs/contrac... [2] - http://www.jsf.mil/downloads/down_documentation.htm http://www.jsf.mil/downloads/down_documentation.htm [3] - http://compass.informatik.rwth-aachen.de/ws-slides/havelund.pdf http://compass.informatik.rwth-aachen.de/ws-slides/havelund.... [4] - http://www.pcworld.com/article/260883/tesla_cto_talks_model_s_batteries_and_incar_linux.html http://www.pcworld.com/article/260883/tesla_cto_talks_model_... [5] - http://msdn.microsoft.com/en-us/library/8ef0s5kh.aspx http://msdn.microsoft.com/en-us/library/8ef0s5kh.aspx
- betterunix 13y ago
  "Reliability and security requirements are up to the developer to impose on any language" This is a common fallback in these discussions, but it is misguided. Yes, you have to work to make software secure in any language; no, this does not mean C is equivalent. In C, you still need to worry about high-level problems like SQL injection, while simultaneously having to worry about low-level problems like integer overflows, dangling pointers, etc. That critical systems have been written in C or C++ is not relevant -- it does not mean that it was a good idea to do so.
  - trimbo 13y ago
    Well, I actually see that as an advantage vs. placing trust in an abstraction you have no control over that can provide security problems for you. So I guess we'll agree to disagree on this one. Curious though, in what would you implement the examples I gave?
pjmlp 13y ago
As a Turbo Pascal refugee, I agree 100%
zedshaw 13y ago
Not really. What we need is people not learning C (or any language) without also learning how writing it wrong causes defects. In my book (mentioned in the post) I have students using Valgrind and attempting to break their code starting at the 4th lesson. I also show them how and why to avoid defects in C. Instead of saying "no new C", we should probably be approaching it with a two-pronged attack. First, tracking down bad educational material and making sure new C coders learn how to make safer C. Second, fixing the older code so that it is safe by default, rather than only in the context of the code it's written in. But, yeah pipe dreams and all, so I just work on improving the educational material.
- Intermernet 13y ago
  Thanks Zed, I really can't upvote you enough! I absolutely love the style of your writing, and the "hard-way" approach to teaching. Keep up the great work :-)
pointyhats 13y ago
C is easy to get right. Its also easy to get wrong. To be honest, most holes I've seen over the years are above the level of the language and are down to the implementation or design being flawed. For example SQL injection, silly business processes, elevation flaws, bad maths etc.
koffiezet 13y ago
When I read "C code" in this thread - I assume people mean C and C++ together, since they're both capable of the same low-level stuff. The thing is, the new compilers, static analysis, JIT'ing, ... available these days for C++ makes it the best time ever to write C++ in a reliable way, and being technology that is being used in the real world, this will only improve. There's a reason the C++ language is undergoing a lot of changes nowadays, for the better. After years of no movement at all, C++11 finally arrived, supporting features improving general reliability and memory-management (single pointers, smart pointers, auto type, ...), and C++14 is on it's way. While old programs will still work, the core language evolves and so do the generally accepted standard/best practices, that when generally accepted provide very reliable code. I work on quite a large C++ code-base, and both our test-team and static analysis tools rarely find "programming errors". Functional bugs - sure, you still have those like you have in any program, but real end-of-the-world memory corruptions or leaks are rare to completely absent. The only tricky part I guess is threading, although analysis tools have massively improved here - and this is an issue in pretty much every language that understands threads. The nice thing about learning C is that you get to understand what exactly is happening, and while a functional language like Haskell is very cool and can in certain situations offer massive optimizations due to it's language and runtime design, it presents you with a non-existing world. C is an "easy" way to understand low-level for as far as it's useful. I fooled around with a lot of languages, including Haskell - and knowing C gives you a much better insight in what the runtime is actually doing, because you KNOW a CPU doesn't work like that, and you're able to quickly understand it's limitations and advantages. Another way to understand what happens +- on CPU level is implementing a simple bytecode compiler and interpreter - in any language of your choosing, but for some reason, most "real world" interpreters are implemented in C/C++.

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
  > There is no particularly good reason for C to be anywhere in the software stack; Really? Not anywhere? Who is handling your hardware interrupts? How is your keyboard and mouse input being handled? What about your video card drivers? Now I will grant that you can bootstrap an initial run time in assembly and place your favorite high level language4 on top of that, if you add extensions to your favorite language to better interact with HW you can do everything in a higher level language, but as it stands, LISP doesn't have built in support for doing a DMA copy from memory buffer to a USB port. My question then becomes, why the heck bootstrap in ASM rather than C?
  - austinz 13y ago
    Agreed; OS kernels and firmware for embedded systems all require low-level access to hardware in a way that high-level desktop applications do not. Being able to easily reason about how C is going to use resources and be compiled down to machine code for the architecture you are using can sometimes be an important asset.
    - tracker1 13y ago
      I think that the point is that even if you accept that the kernel level code and device drivers are all in C, from there, there's less and less benefit to doing userland code in C from there... you could use Lisp, Erlang, Scheme or a number of other languages for userland and service oriented code. Although I really don't care for Unity, or Windows 8's UI's I do appreciate some of the directions they are going in terms of being able to create applications that are more abstracted in nature. I personally happen to like higher level languages/environments, and modern hardware has been able to handle them very well for years. I do think that certain patterns and practices that people have followed need to be re-thought for parallelism, and that a thread/process per request in service oriented architectures has now been a bottleneck... but there are techniques, languages and platforms that can take us much farther without digging into a low-level platform language like C. I agree that knowing C is helpful, so is knowing assembly... that doesn't mean even a small fraction of developers should be working with them on a daily basis. Most code is one-off line of business application code and related services. It doesn't need sheer performance, it needs to be done and in production sooner... the next thing needs to get done. You can't create software as quickly in C/Assembly as you can in Java/C# (or Python, Ruby, NodeJS).

fdr_cs 13y ago

its not about writing new code in C. Its about learning how you prefered language is implemented. Learn your tools , its really important.

nemo1618 13y ago

I wouldn't say this article is recommending that you go out and program in C full-time. Many people have learned Lisp (and are better programmers for it), but few actually use it at their day job.

kmm 13y ago

Was there any study done to the (un)reliability of C? I know for a fact practically every piece software I use is programmed in either C or C++. The sole exceptions are Anki and Gentoo's portage system, both Python. And I'm pretty sure the reason portage is so extremely slow is because it is in Python (I've checked, it's not I/O-bound). And Anki is some very unreliable software. In fact, give me a single big desktop software project made with a language that is not C or C++.

betterunix 13y ago
"I know for a fact practically every piece software I use is programmed in either C or C++." How confident are you that that software will work as expected? How much are you willing to bet? The fact that a language is popular does not prove that the language is good, nor that it should be used, nor that it is not causing us problems. Just the other day on HN, there was an article about a massive number of vulnerabilities in X11 applications -- all resulting from problems that you have in C and C++ but not in higher-level languages. Entire classes of bugs that are common problems in C are just not an issue in other languages. Sure, it is possible to write unreliable code in high-level languages. It is just a lot easier to write unreliable C code, and C programmers are much more likely to do so (even those with years of experience).
- Jabbles 13y ago
  "There are only two kinds of languages: the ones people complain about and the ones nobody uses" Bjarne Stroustrup http://www.stroustrup.com/bs_faq.html#really-say-that http://www.stroustrup.com/bs_faq.html#really-say-that Of course, that just dismisses the criticism of the language. But to say that it "should [not] be used" ignores the current landscape of engineers, employers and problems.
  - pjscott 13y ago
    That quote is always annoying, because it applies equally well to all criticisms of any programming language in active use, but not all criticisms are created equal. A useful heuristic would actually help distinguish between reasonable criticism and inevitable kvetching.

trimbo 13y ago

> We already have a problem with a massive, unreliable, insecure ecosystem of legacy C code A ton of the world's software with the highest reliability requirements is written in C and C++. Nuclear power plants? Yes. [1] Joint Strike Fighter? Yes. [2] Mars rover? Yes. [3] Your Tesla? Yes [4] US telephone systems. Stock exchanges. Bloomberg. Your cell phone OS (incl. many years before smartphones). The list goes on and on. C and C++ are the most general and well-supported languages we have. They can solve problems on any architecture with a good tradeoff between efficiency and generality (over assembly) and predictable performance. Reliability and security requirements are up to the developer to impose on any language (see: the github PHP SQL injection search). C is not, in itself, a problem towards these goals and those who build upon C are always improving it [5]. [1] - http://www.nrc.gov/reading-rm/doc-collections/nuregs/contract/cr6463/ http://www.nrc.gov/reading-rm/doc-collections/nuregs/contrac... [2] - http://www.jsf.mil/downloads/down_documentation.htm http://www.jsf.mil/downloads/down_documentation.htm [3] - http://compass.informatik.rwth-aachen.de/ws-slides/havelund.pdf http://compass.informatik.rwth-aachen.de/ws-slides/havelund.... [4] - http://www.pcworld.com/article/260883/tesla_cto_talks_model_s_batteries_and_incar_linux.html http://www.pcworld.com/article/260883/tesla_cto_talks_model_... [5] - http://msdn.microsoft.com/en-us/library/8ef0s5kh.aspx http://msdn.microsoft.com/en-us/library/8ef0s5kh.aspx

betterunix 13y ago
"Reliability and security requirements are up to the developer to impose on any language" This is a common fallback in these discussions, but it is misguided. Yes, you have to work to make software secure in any language; no, this does not mean C is equivalent. In C, you still need to worry about high-level problems like SQL injection, while simultaneously having to worry about low-level problems like integer overflows, dangling pointers, etc. That critical systems have been written in C or C++ is not relevant -- it does not mean that it was a good idea to do so.
- trimbo 13y ago
  Well, I actually see that as an advantage vs. placing trust in an abstraction you have no control over that can provide security problems for you. So I guess we'll agree to disagree on this one. Curious though, in what would you implement the examples I gave?

pjmlp 13y ago

As a Turbo Pascal refugee, I agree 100%

zedshaw 13y ago

Not really. What we need is people not learning C (or any language) without also learning how writing it wrong causes defects. In my book (mentioned in the post) I have students using Valgrind and attempting to break their code starting at the 4th lesson. I also show them how and why to avoid defects in C. Instead of saying "no new C", we should probably be approaching it with a two-pronged attack. First, tracking down bad educational material and making sure new C coders learn how to make safer C. Second, fixing the older code so that it is safe by default, rather than only in the context of the code it's written in. But, yeah pipe dreams and all, so I just work on improving the educational material.

Intermernet 13y ago
Thanks Zed, I really can't upvote you enough! I absolutely love the style of your writing, and the "hard-way" approach to teaching. Keep up the great work :-)

pointyhats 13y ago

C is easy to get right. Its also easy to get wrong. To be honest, most holes I've seen over the years are above the level of the language and are down to the implementation or design being flawed. For example SQL injection, silly business processes, elevation flaws, bad maths etc.

koffiezet 13y ago

When I read "C code" in this thread - I assume people mean C and C++ together, since they're both capable of the same low-level stuff. The thing is, the new compilers, static analysis, JIT'ing, ... available these days for C++ makes it the best time ever to write C++ in a reliable way, and being technology that is being used in the real world, this will only improve. There's a reason the C++ language is undergoing a lot of changes nowadays, for the better. After years of no movement at all, C++11 finally arrived, supporting features improving general reliability and memory-management (single pointers, smart pointers, auto type, ...), and C++14 is on it's way. While old programs will still work, the core language evolves and so do the generally accepted standard/best practices, that when generally accepted provide very reliable code. I work on quite a large C++ code-base, and both our test-team and static analysis tools rarely find "programming errors". Functional bugs - sure, you still have those like you have in any program, but real end-of-the-world memory corruptions or leaks are rare to completely absent. The only tricky part I guess is threading, although analysis tools have massively improved here - and this is an issue in pretty much every language that understands threads. The nice thing about learning C is that you get to understand what exactly is happening, and while a functional language like Haskell is very cool and can in certain situations offer massive optimizations due to it's language and runtime design, it presents you with a non-existing world. C is an "easy" way to understand low-level for as far as it's useful. I fooled around with a lot of languages, including Haskell - and knowing C gives you a much better insight in what the runtime is actually doing, because you KNOW a CPU doesn't work like that, and you're able to quickly understand it's limitations and advantages. Another way to understand what happens +- on CPU level is implementing a simple bytecode compiler and interpreter - in any language of your choosing, but for some reason, most "real world" interpreters are implemented in C/C++.