8 ms·

Ironic that he begins by taking issue with the idea that you should avoid writing C if you can, then proceeds to provide the best evidence possible for why it's

Ironic that he begins by taking issue with the idea that you should avoid writing C if you can, then proceeds to provide the best evidence possible for why it's true. Why on Earth would you voluntarily code in a language where people can debate something as simple as which type to use for integers, unless you absolutely had to?

EliRivers 11y ago
Because it's simple and low-overhead and compilers for it exist on every lump of hardware I've ever had to work with, from a clunky x64 to a PIC to a TigerSHARC to a bizarre DSP thingy from a tiny fab lab somewhere. A great many of the problems that people experience with C code can actually be nullified (zing!) by finding a competent C programmer who does the job properly. A tool being easy to misuse doesn't mean we shouldn't use it; it just means we should demand high standards of the programmers and not employ some chancer who learned how to program from the back of a cereal packet. I give young children plastic safety scissors. I give competent adults chainsaws and scalpels.
- ketzu 11y ago
  I think what the discussion about this statement misses is the "unless you need to" part. There are cases where you should use C! It is not "never ever use C". If the use-case is being able to run on everything from TigerSHARC to x64, you probably should use C. If you want a GUI based Windows App or a webapplication, that might not be a "you need to use C" case.
- pjmlp 11y ago
  See, that is the problem right there. Even if one does find such competent programmers, I doubt they the way C culture works it would help. Most C devs I have met, if given a memory safe systems programming language like Modula-2 or Rust, would just use SYSTEM or unsafe {} everywhere without any proof of a profiler if it really matters to the customer. As for being available everywhere, that is an historical accident of C's adoption. I remember when C was only available in UNIX and we had things like RatC.
  - omgtehlion 11y ago
    heck, even in c# I use unsafe{} here and there ((
    - NoGravitas 11y ago
      ))
      - mchahn 11y ago
        ;
  - EliRivers 11y ago
    Slightly off-topic, I'd say that the majority of programmers, C devs included, are barely competent. They know enough to bash through to something clunky and dangerous that kind of does what's needed at a demo. Whilst it's true that taking away all the dangerous tools would make it harder for this great sea of perpetual amateurs to do so much damage, I think it's not right to blame the tools. By simply being here and reading this, you're almost by definition in the top 20% of programmers. Hyperbole, yes, and counter-examples exist, but anyone who routinely comes here will improve; the majority of programmers never do.
- stupidcar 11y ago
  Again, if people can't agree what type to use for integers, then it's not "simple". And yes, a tool being easy to misuse absolutely means we shouldn't use it unless we have to. A competent adult would never use a chainsaw or a scalpel except for tasks where nothing else would work.
  - EliRivers 11y ago
    Pick the integer type that is best suited for your use, given your circumstances. I can't make it any simpler. There is no one true magical perfect solution for all circumstances in all places at all times. This is why I employ competent programmers; to make these choices. A competent adult would never use a chainsaw or a scalpel except for tasks where nothing else would work. Of course they would. I do, frequently; not chainsaws and scalpels, but there are dangerous tools that I am really good with that I can produce really good work with, quickly and efficiently, and there are safe tools that would mean I take longer and can't do exactly what I want to do and produce a less satisfactory result. I don't pick the safe tool; I pick the right tool for the job, given the circumstances and the requirements. Are there people who deliberately pick the tool that will give a worse outcome? If one of the tools available is something that the person using it isn't competent to use, that doesn't mean the problem is with the tool. I freely accept that a good C programmer needs knowledge and experience beyond that of many programmers. This is not somehow a bad thing.
    - anon1385 11y ago
      >Pick the integer type that is best suited for your use, given your circumstances. >Pick the fission reactor type that is best suited for your use, given your circumstances.
      - EliRivers 11y ago
        I cannot tell if you are in favour of, or against, the principle that one should pick the right tool for the job.
        11y ago
- lucian1900 11y ago
  As a society, we still avoid tools that are easy to misuse whenever we can. Modern chainsaws have several safety features that were missing from earlier ones and that doesn't make them less useful. Just because the most popular systems language is dangerously unsafe doesn't mean a safe alternative couldn't replace it (like, say, Rust).
- Avshalom 11y ago
  Those compilers exist because of path dependency from unix not from any unique qualities of C
  - EliRivers 11y ago
    This makes no sense and I believe you are incorrect. When Analog Devices churned out the TigerSHARC processor, they did not decide to write a C compiler for it because of unix path dependencies.
    - pjmlp 11y ago
      C become widespread because of UNIX, just like JavaScript got widespread because of the browsers ubiquity. Eventually developers wanted to take home to their 8 bit computers what they were coding at the university and work. So RatC, Small-C and many other C dialects were born. Just like node.js nowadays, with UNIX adoption becoming the basis of the 80's graphical workstations, the pressure to have easy access to C compilers increased. Also back in the day, one paid for compilers, so the majority went to whatever what the OS official system programming language. So this is how we ended up in this situation.
    - Avshalom 11y ago
      When Analog Devices churned out the TigerSHARC processor they wrote a c compiler because "C is what you use for low level code" not Forth, Pascal, Modula, Ada, Fortran, Algol, a lisp or any of the other hundreds of programming languages that have been used to write programs directly on metal on computers that the TigerSHARC outclasses by magnitudes. and "c is what you use for low level code" because decades of Unix. Decades of C being the lowest (non-assembly) level of programmers' systems, decades of being the only language that doesn't make you install an additional runtime, decades of accumulated wisdom... But those are a side effects of Unix winning, not C qua C.
- krylon 11y ago
  The key phrase here is "if you can avoid it". When your target platform is an 8-bit microcontroller or an embedded system with hard real-time requirements, your options are very limited. But there are plenty of situations where there are alternatives, and often these allow you to solve your problem in less time, with much lower risk of bugs than in C. As always in life, one has to evaluate one's options, consider their respective advantages and weaknesses and then make a choice. If I had to write a document like that, I would use a different phrasing from "if you can avoid it". But the sentiment - to avoid using C where superior alternatives exist[1] - is something I agree with. > A great many of the problems that people experience with C code can actually be nullified (zing!) by finding a competent C programmer who does the job properly. That is kind of like saying the solution to traffic accidents is only letting people drive that don't cause accidents or demand of people that they drive sufficiently carefully. Sure, that is something worth wishing for - but it is not very realistic to expect this to actually happen. Not that I disagree that C is a very demanding language. Even the best programmers make mistakes. But this is the reason the author of the original document the linked article refers to advised people to avoid C where possible. Most programmers will be better off for most of their projects with a language like Go, or Python or whatever. [1] Of course, if by "alternatives" I mean languages like Perl, Python or Ruby, it is worth keeping in mind that their main implementations are written in C.
  - whyever 11y ago
    > to avoid using C where superior alternatives exist is something I agree with. Who wouldn't?
  - LeonidasXIV 11y ago
    > When your target platform is an 8-bit microcontroller Funnily enough, you could use OCaml on PIC18 (which are as far as I know 8-bit microcontrollers) using OcaPIC[1]. I was thinking of getting one of those and implementing a keyboard firmware on it. [1] http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=ocapic http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=oca...
  - pjmlp 11y ago
    > When your target platform is an 8-bit microcontroller or an embedded system with hard real-time requirements, your options are very limited. You mean like the CPUs supported by MikroElektronika's Pascal and Basic compilers? http://www.mikroe.com/8051/ http://www.mikroe.com/8051/ http://www.mikroe.com/pic/ http://www.mikroe.com/pic/ http://www.mikroe.com/avr/ http://www.mikroe.com/avr/
dietrichepp 11y ago
This comment only fans the flames of language war, it doesn't contribute to the discussion.
- logicallee 11y ago
  This is simply not true. The barrier to a NEW person starting to write C code in 2016 - imagine some 20 year old college student - is "Am I ready to pick a denomination and religion and read hundreds to thousands of pages of gospel?" There is no such barrier with any other language. You literally cannot give any examples of correct C code as a solution to a problem: literally, experts will disagree with you. I've had experts tell me that cplusplus.com/reference gives horrific examples you should never follow. The newest addition of The C++ Programming Language says that the examples are not meant to be production code you can actually use as-is. (I can dig this up later if you want.) C and C++ are more debates in the form of a language than languages per se.
  - dietrichepp 11y ago
    This is exactly my point. You're basically telling me that C is a horrible language. Why? Do you think I disagree with you? Do you think that you're giving me new information? Or are you just doing your part in the language war, perhaps repeating talking points that we're frankly a bit tired of? There are better things we could be talking about.
    - logicallee 11y ago
      I didn't say C++ is a horrible language, and I'm sure I didn't say it because I don't really think this. I would think you're being downvoted because there aren't really any language wars around the choice of C/C++ - it's not like PHP vs Ruby or Python or something. You're imagining a war where there really isn't one. Usually people writing C or C++ don't have much of a choice, and usually people choose these languages due to the requirements. For example, writing embedded microcontroller code that will run on a $0.70 chip. What are you going to do, write it in Rust? Nobody would dream of telling Linus Torvalds to refactor the Linux kernel into some other language - it's not just a ridiculous suggestion, it's like asking the United States to move to a different continent - it's a total non sequitur, it's not even in the realm of possibility. Basically the advice "you should avoid writing C if you can" is totally uncontroversial, and for I would say 99% of people who woke up today, January 15th, 2016, a weekday, and wrote C code, the answer to "can you avoid it" is no. (Not just due to their position/employment but due to the very requirements of the project itself.) Sure you should avoid writing C and C++ when you can, but for some classes of problems that is "never."
hamiltonkibbe 11y ago
You voluntarily code in C for the same reason that your OS kernel's 'yield' is written in assembly. How do you push the addressing mode register to the stack when switching to another task in your high level language of choice?
- Roboprog 11y ago
  I like how the old Borland Turbo Pascal had little extensions to let you move data between program variables and registers, as well as put in little bits of assembler. Of course, that only worked on x86 on MS-DOS :-(
kbart 11y ago
"Why on Earth would you voluntarily code in a language where people can debate something as simple as which type to use for integers, unless you absolutely had to?" Because we have no alternatives so far. I do C programming for a living, but I'd be more than happy if there were some type and memory safe language I could use to program any tiny, obscure MCU, that could stay at least in the same order of magnitude of speed and let access hardware easily. Rust might be a step in a right direction, but it still has a looong way to go to become a viable alternative to C in embedded world. Of course, for a modern, high level development (web, mobile etc.), I see no reason to use C (maybe except for tiny libraries or co-routines where speed is critical). C is simply a tool -- it's neither good, nor bad -- and as every tool, it has it's use. You can easily break your fingers with a hammer, but that doesn't mean that it's a bad tool for driving nails in.
- oldmanjay 11y ago
  You're aware that "we have no choice" does not answer a question about why you would do something voluntarily, right?
  - kbart 11y ago
    I just confirm, that majority of C programmers nowadays do that because of "they absolutely had to".
- briansmith 11y ago
  What do you think Rust needs to do to become viable in the embedded world?
  - kbart 11y ago
    Ecosystem and community. Most of the time you can find what you need in C already written, in Rust it's do-it-yourself now.

EliRivers 11y ago

Because it's simple and low-overhead and compilers for it exist on every lump of hardware I've ever had to work with, from a clunky x64 to a PIC to a TigerSHARC to a bizarre DSP thingy from a tiny fab lab somewhere. A great many of the problems that people experience with C code can actually be nullified (zing!) by finding a competent C programmer who does the job properly. A tool being easy to misuse doesn't mean we shouldn't use it; it just means we should demand high standards of the programmers and not employ some chancer who learned how to program from the back of a cereal packet. I give young children plastic safety scissors. I give competent adults chainsaws and scalpels.

ketzu 11y ago
I think what the discussion about this statement misses is the "unless you need to" part. There are cases where you should use C! It is not "never ever use C". If the use-case is being able to run on everything from TigerSHARC to x64, you probably should use C. If you want a GUI based Windows App or a webapplication, that might not be a "you need to use C" case.
pjmlp 11y ago
See, that is the problem right there. Even if one does find such competent programmers, I doubt they the way C culture works it would help. Most C devs I have met, if given a memory safe systems programming language like Modula-2 or Rust, would just use SYSTEM or unsafe {} everywhere without any proof of a profiler if it really matters to the customer. As for being available everywhere, that is an historical accident of C's adoption. I remember when C was only available in UNIX and we had things like RatC.
- omgtehlion 11y ago
  heck, even in c# I use unsafe{} here and there ((
  - NoGravitas 11y ago
    ))
    - mchahn 11y ago
      ;
- EliRivers 11y ago
  Slightly off-topic, I'd say that the majority of programmers, C devs included, are barely competent. They know enough to bash through to something clunky and dangerous that kind of does what's needed at a demo. Whilst it's true that taking away all the dangerous tools would make it harder for this great sea of perpetual amateurs to do so much damage, I think it's not right to blame the tools. By simply being here and reading this, you're almost by definition in the top 20% of programmers. Hyperbole, yes, and counter-examples exist, but anyone who routinely comes here will improve; the majority of programmers never do.
stupidcar 11y ago
Again, if people can't agree what type to use for integers, then it's not "simple". And yes, a tool being easy to misuse absolutely means we shouldn't use it unless we have to. A competent adult would never use a chainsaw or a scalpel except for tasks where nothing else would work.
- EliRivers 11y ago
  Pick the integer type that is best suited for your use, given your circumstances. I can't make it any simpler. There is no one true magical perfect solution for all circumstances in all places at all times. This is why I employ competent programmers; to make these choices. A competent adult would never use a chainsaw or a scalpel except for tasks where nothing else would work. Of course they would. I do, frequently; not chainsaws and scalpels, but there are dangerous tools that I am really good with that I can produce really good work with, quickly and efficiently, and there are safe tools that would mean I take longer and can't do exactly what I want to do and produce a less satisfactory result. I don't pick the safe tool; I pick the right tool for the job, given the circumstances and the requirements. Are there people who deliberately pick the tool that will give a worse outcome? If one of the tools available is something that the person using it isn't competent to use, that doesn't mean the problem is with the tool. I freely accept that a good C programmer needs knowledge and experience beyond that of many programmers. This is not somehow a bad thing.
  - anon1385 11y ago
    >Pick the integer type that is best suited for your use, given your circumstances. >Pick the fission reactor type that is best suited for your use, given your circumstances.
    - EliRivers 11y ago
      I cannot tell if you are in favour of, or against, the principle that one should pick the right tool for the job.
      - 11y ago
lucian1900 11y ago
As a society, we still avoid tools that are easy to misuse whenever we can. Modern chainsaws have several safety features that were missing from earlier ones and that doesn't make them less useful. Just because the most popular systems language is dangerously unsafe doesn't mean a safe alternative couldn't replace it (like, say, Rust).
Avshalom 11y ago
Those compilers exist because of path dependency from unix not from any unique qualities of C
- EliRivers 11y ago
  This makes no sense and I believe you are incorrect. When Analog Devices churned out the TigerSHARC processor, they did not decide to write a C compiler for it because of unix path dependencies.
  - pjmlp 11y ago
    C become widespread because of UNIX, just like JavaScript got widespread because of the browsers ubiquity. Eventually developers wanted to take home to their 8 bit computers what they were coding at the university and work. So RatC, Small-C and many other C dialects were born. Just like node.js nowadays, with UNIX adoption becoming the basis of the 80's graphical workstations, the pressure to have easy access to C compilers increased. Also back in the day, one paid for compilers, so the majority went to whatever what the OS official system programming language. So this is how we ended up in this situation.
  - Avshalom 11y ago
    When Analog Devices churned out the TigerSHARC processor they wrote a c compiler because "C is what you use for low level code" not Forth, Pascal, Modula, Ada, Fortran, Algol, a lisp or any of the other hundreds of programming languages that have been used to write programs directly on metal on computers that the TigerSHARC outclasses by magnitudes. and "c is what you use for low level code" because decades of Unix. Decades of C being the lowest (non-assembly) level of programmers' systems, decades of being the only language that doesn't make you install an additional runtime, decades of accumulated wisdom... But those are a side effects of Unix winning, not C qua C.
krylon 11y ago
The key phrase here is "if you can avoid it". When your target platform is an 8-bit microcontroller or an embedded system with hard real-time requirements, your options are very limited. But there are plenty of situations where there are alternatives, and often these allow you to solve your problem in less time, with much lower risk of bugs than in C. As always in life, one has to evaluate one's options, consider their respective advantages and weaknesses and then make a choice. If I had to write a document like that, I would use a different phrasing from "if you can avoid it". But the sentiment - to avoid using C where superior alternatives exist[1] - is something I agree with. > A great many of the problems that people experience with C code can actually be nullified (zing!) by finding a competent C programmer who does the job properly. That is kind of like saying the solution to traffic accidents is only letting people drive that don't cause accidents or demand of people that they drive sufficiently carefully. Sure, that is something worth wishing for - but it is not very realistic to expect this to actually happen. Not that I disagree that C is a very demanding language. Even the best programmers make mistakes. But this is the reason the author of the original document the linked article refers to advised people to avoid C where possible. Most programmers will be better off for most of their projects with a language like Go, or Python or whatever. [1] Of course, if by "alternatives" I mean languages like Perl, Python or Ruby, it is worth keeping in mind that their main implementations are written in C.
- whyever 11y ago
  > to avoid using C where superior alternatives exist is something I agree with. Who wouldn't?
- LeonidasXIV 11y ago
  > When your target platform is an 8-bit microcontroller Funnily enough, you could use OCaml on PIC18 (which are as far as I know 8-bit microcontrollers) using OcaPIC[1]. I was thinking of getting one of those and implementing a keyboard firmware on it. [1] http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=ocapic http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=oca...
- pjmlp 11y ago
  > When your target platform is an 8-bit microcontroller or an embedded system with hard real-time requirements, your options are very limited. You mean like the CPUs supported by MikroElektronika's Pascal and Basic compilers? http://www.mikroe.com/8051/ http://www.mikroe.com/8051/ http://www.mikroe.com/pic/ http://www.mikroe.com/pic/ http://www.mikroe.com/avr/ http://www.mikroe.com/avr/

dietrichepp 11y ago

This comment only fans the flames of language war, it doesn't contribute to the discussion.

logicallee 11y ago
This is simply not true. The barrier to a NEW person starting to write C code in 2016 - imagine some 20 year old college student - is "Am I ready to pick a denomination and religion and read hundreds to thousands of pages of gospel?" There is no such barrier with any other language. You literally cannot give any examples of correct C code as a solution to a problem: literally, experts will disagree with you. I've had experts tell me that cplusplus.com/reference gives horrific examples you should never follow. The newest addition of The C++ Programming Language says that the examples are not meant to be production code you can actually use as-is. (I can dig this up later if you want.) C and C++ are more debates in the form of a language than languages per se.
- dietrichepp 11y ago
  This is exactly my point. You're basically telling me that C is a horrible language. Why? Do you think I disagree with you? Do you think that you're giving me new information? Or are you just doing your part in the language war, perhaps repeating talking points that we're frankly a bit tired of? There are better things we could be talking about.
  - logicallee 11y ago
    I didn't say C++ is a horrible language, and I'm sure I didn't say it because I don't really think this. I would think you're being downvoted because there aren't really any language wars around the choice of C/C++ - it's not like PHP vs Ruby or Python or something. You're imagining a war where there really isn't one. Usually people writing C or C++ don't have much of a choice, and usually people choose these languages due to the requirements. For example, writing embedded microcontroller code that will run on a $0.70 chip. What are you going to do, write it in Rust? Nobody would dream of telling Linus Torvalds to refactor the Linux kernel into some other language - it's not just a ridiculous suggestion, it's like asking the United States to move to a different continent - it's a total non sequitur, it's not even in the realm of possibility. Basically the advice "you should avoid writing C if you can" is totally uncontroversial, and for I would say 99% of people who woke up today, January 15th, 2016, a weekday, and wrote C code, the answer to "can you avoid it" is no. (Not just due to their position/employment but due to the very requirements of the project itself.) Sure you should avoid writing C and C++ when you can, but for some classes of problems that is "never."

hamiltonkibbe 11y ago

You voluntarily code in C for the same reason that your OS kernel's 'yield' is written in assembly. How do you push the addressing mode register to the stack when switching to another task in your high level language of choice?

Roboprog 11y ago
I like how the old Borland Turbo Pascal had little extensions to let you move data between program variables and registers, as well as put in little bits of assembler. Of course, that only worked on x86 on MS-DOS :-(

kbart 11y ago

"Why on Earth would you voluntarily code in a language where people can debate something as simple as which type to use for integers, unless you absolutely had to?" Because we have no alternatives so far. I do C programming for a living, but I'd be more than happy if there were some type and memory safe language I could use to program any tiny, obscure MCU, that could stay at least in the same order of magnitude of speed and let access hardware easily. Rust might be a step in a right direction, but it still has a looong way to go to become a viable alternative to C in embedded world. Of course, for a modern, high level development (web, mobile etc.), I see no reason to use C (maybe except for tiny libraries or co-routines where speed is critical). C is simply a tool -- it's neither good, nor bad -- and as every tool, it has it's use. You can easily break your fingers with a hammer, but that doesn't mean that it's a bad tool for driving nails in.

oldmanjay 11y ago
You're aware that "we have no choice" does not answer a question about why you would do something voluntarily, right?
- kbart 11y ago
  I just confirm, that majority of C programmers nowadays do that because of "they absolutely had to".
briansmith 11y ago
What do you think Rust needs to do to become viable in the embedded world?
- kbart 11y ago
  Ecosystem and community. Most of the time you can find what you need in C already written, in Rust it's do-it-yourself now.