Why do people use dynamite if its so dangerous? Because its also powerful.

Just like any other programming language, if you don't know what you're doing, you'll introduce bugs and security holes. C is just different in the sense that it does not do much hand holding, so there are actually quite a few things you have to know not to shoot yourself in the foot.

@VincentSavard It's quite the opposite, actually. In most other programming languages, you have to really go out of your way to introduce security holes, because they're safe by default, by design. In C, doing things the obvious way is what's likely to cause trouble.

it helps to realize that C is safer than pure assembly. And those other languages need to be implemented in something. The compilers for those languages can be self-hosted (The current C# compiler is written in C#, for instance) but the runtime can't be written in the language itself. However, the C runtime typically can be written in C.

The last application I wrote for work I had to control a 10000 ampere welding pulse during a couple of milliseconds and run on a controller with 64 kB of RAM. Visual basic was not my first choice.

@imallett You might be a god among men, or your applications is quite simple, or your code is not under attack. The long & wide record of critical issues coming from memory unsafety (example: every major browser) suggests that C (and C++) is, on average, indeed dangerous. One might infer that the software engineering world is overflowing with idiots (a quite arrogant judgement), but even if that were the case, it still means that using C is statistically irresponsible.

I think the main goal of C is to reify the most used hardware concepts of the past years so that people can program them with an abstract and reusable language. OTOH Java, C# and so so, try to abstract the (important) part of programming related to "making business". Also C is no special in that, Pascal could have been used too if it were not for the verbosity. Finally one good point, to me, for playing with C is that doing things from scratch the first time you see it ("you can't use it if you can't make it"), at least conceptually, keep your brain fit and widen your understanding.

@delnan As I said, minority opinion. But to clarify a bit: I find that most of the things people claim as "dangerous" actually are rendered quite safe with good programming practice, (as should be applied to any language). The rest are people abusing language features or otherwise using them incorrectly. These problems go away with proper training. I know people still disagree with all that, but I still offer it as my experience from industry.

A) It's relatively easy to implement (especially since several open source kits are available). B) It's powerful -- gives access to pretty much the whole machine, with relatively few hoops to jump through. C) It's easy to understand and broadly understood. D) It's efficient, if used properly. E) Boys like to play with sharp knives.

C has been referred to as "high-level assembler". In a way, that's the answer to this question; if your alternative is to write it in assembler, C is often a better choice. Some folks are comfortable working at that level, some aren't. Pick the tool that matches the task, matches your style, and is available; there no "best".

Do you think the language is 'dangerous' because of the term pointer and you fear cutting yourself on one of them? No, they're not really sharp: it's just a computer concept. Also you can do similar 'dangerous' or easy-to-fail stuff in java or whatever other language

Some of them simply dont want to learn other programming languages "because we can do anything in C".

Why do people drive ferraris if driving one too fast into a wall can kill you? Because it's not the ferrari that kills you, it's the "driving too fast into a wall" that kills you.

So one answer is "machismo". Nothing wrong with that; without technical machismo I wouldn't have a career and the industry wouldn't have guys who can write solid device drivers.

The same reason people use chainsaws instead of butter knives, or explosives instead of hammers. To look at it metaphorically, something like C# or Java provides you with engines, gearboxes, differentials etc, while C gives you sheet metal and a spanner and expects you to figure it out. Sure, you have to build everything yourself, but anything you don't build or use isn't there to weigh you down, and if what you need above all else is speed, shedding weight is a good idea. Just remember there's nothing to protect you from any mistakes you make - which is fine, so long as you don't make any.

@MasonWheeler: With a bit more experience, "the obvious way" will no longer be "the wrong way".

C isn't 'dangerous' in and of itself. C in the hands of sloppy programmers can be 'dangerous'. If you use a scanf to read into a tiny buffer, it's not C's fault that you've just made a giant security hole, it's yours. C requires that you understand the implications of what you ask it to do, because it will do exactly that, and not hold your hand and tell you if you've been a naughty programmer.

@GrandmasterB, nice analogy, but before there was Dynamite, they used to use nitroglycerine. Nobody uses nitroglycerine anymore because Dynamite was safer, and nobody uses Dynamite anymore because Gelignite is safer still. Still very powerful, still considered too dangerous to keep on the shelves at the DIY store, but there are degrees of danger.

The C language is the most direct high-level representation of the Von Neumann architecture. It's "dangerous" and powerful because it exposes the hardware's capabilities directly to you.

@RoyTinker No, it's dangerous because it lies to you. If I declare an array buffer with 10 elements, and then it has no problem at all with me trying to write to element 11 of that buffer, then the array is a lie.

@MasonWheeler the Von Neumann architecture has no built-in notion of an "array", so C arrays (and many other language features) are semantic abstractions. As such, at the language level, they can provide no checks that the hardware itself doesn't support. (Note I'm not talking about libraries and such, where such features implemented in software can be used by C programs).

@RoyTinker Why would you want to write applications, particularly ones that connect to the internet and receive untrusted data, on a raw RAM machine / Von Neumann machine that doesn't separate code and data and instead requires the programmer to repeatedly avoid numerous subtle pitfalls to prevent bugs / security exploits?

@RoyTinker Nope. If they were semantic abstractions, they would have semantics that fit the abstraction. What they are is lies, pretending to be an array with well-defined bounds while not actually providing such functionality. (And if the language can't provide any features that the hardware doesn't support directly, what's up with functions? A CPU has no knowledge of any such concept...)

Because they don't know Ada!

@Solomonoff'sSecret I'm not advocating using a raw Von Neumann machine to do modern network programming. Not sure where you got that idea. I'm only pointing out how C is mainly a Von Neumann-oriented language.

@MasonWheeler a leaky abstraction is still an abstraction... I called it "semantic" because C provides semantics that translate directly to machine code (as opposed to language features implemented in software), not because the semantics fit the abstraction well. I'll grant the "leakyness" of some abstractions is a language-level danger, sure. But until "arrays" become a hardware feature, a strictly Von-Neumann oriented language has to accept that problem if it is to provide "arrays" and the like to programmers. The C language must be capable of working without a runtime library.

As a systems programmer, I am frankly unclear that C really is less safe than other languages, at least if you use it intelligently - a modern dialect (not ancient K&R C), with warnings enabled etc. There are plenty of unsafe things you can do with C, and some other languages make a point of preventing those specific things - but I see those languages as having their own risks.