5 ms·

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

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/

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/