152

With all the new "modern" languages out today, how is it that C is still heralded as the fastest and "closest to the machine"? I don't really believe in there ever being only one correct way to do things, and C has been around for a really long time (since the 60's!). Have we really not come up with anything better than something written nearly 50 years ago?

I am aware that modern languages are higher-level and take care of certain tasks like garbage collection and memory allocation and utilize libraries and such. I'm just asking why there has never been a true second option to C.

Can it be that C is so perfect that no other way of operating a computer could be possible (developer-adoption aside)?

EDIT Look, I'm not trying to knock C or whatever your favorite language is. I'm wondering why C has become the standard and why other alternatives never emerged and C was just "accepted".

Jason
  • 2,037
  • 2
  • 17
  • 16
  • 46
    C++ is just as fast and much more productive to write in. <3 – GManNickG Dec 08 '09 at 06:16
  • 6
    um, aren't you forgetting about c++? –  Dec 08 '09 at 06:16
  • 24
    I would argue assembly is the fastest and "closest" to the machine. –  Dec 08 '09 at 06:17
  • 30
    why all the motions to close? i'm really curious... i'm not trying to start flame wars or anything – Jason Dec 08 '09 at 06:18
  • 3
    @alberto - but it's not a good alternative to C – Jason Dec 08 '09 at 06:19
  • 3
    it is like bread or coffee, it is the best. Glad SO doesn't allow downvoting comments (yet) :-) –  Dec 08 '09 at 06:22
  • 3
    I'm disappointed this question was closed. I was in the middle of a pretty detailed response which is now lost. – dj_segfault Dec 08 '09 at 06:23
  • 1
    Aaand we're back! @Jason: Whenever you ask a question inviting comparison of languages or other products, the balance of tradeoffs mean there's no hard and fast "right" answer, and you get a lot of mostly subjective arguing going on. This can get ugly fast, so people tend to err on the side of shutting a question down before it gets out of hand. –  Dec 08 '09 at 06:34
  • @carl - i wasn't really trying to invite comparison. it was more of a "why hasn't this happened yet" type question. i love that people have their own preferences for language, i was just wondering why there's nothing quite like C _at that level_, and why C has pretty much been accepted as the standard for programming... – Jason Dec 08 '09 at 06:45
  • 6
    Depending on use, compiler support, and libraries used, C++ can be faster than C. Well designed dynamic objects whose implementation is resolved at compilation is typically the fastest implementation of: C, C++ polymorphic@runtime, or polymorphic@compilation. C can match that speed, but people don't write it that way (nor should they generally because it equates to a source code explosion), they try to write reusable, maintainable code, which skims speed in practice. With C++, you get all that and object interfaces, type safety... speed/size preference and use is another case. Beyond that, asm – justin Dec 08 '09 at 07:18
  • 4
    Btw, C has not been around since the 60's: http://cm.bell-labs.com/cm/cs/who/dmr/chist.html. Its predecessor B just about has, though. – Steve Jessop Dec 08 '09 at 11:23
  • 2
    for the record, this question has been closed twice and reopened twice, despite 18 upvotes (and only 4 downvotes) and 7 favorites. jeez... – Jason Dec 08 '09 at 20:23
  • I can't recall the titles, but I'm sure we've been over this ground before. –  Dec 09 '09 at 02:04
  • 1
    @dmckee: not sure... I know we've covered "Why does anything still use C++", "Why doesn't everything use C++", "Why isn't everything re-written in C#", and "Why does everyone hate Haskell"... But don't recall this one. – Shog9 Dec 10 '09 at 00:24
  • 18
    closed again? after being reopened by jeff atwood himself? why would you possibly want to close this? – Jason Dec 10 '09 at 19:36
  • 2
    "C++ is just as fast and much more productive to write in.": Any language Y that is a superset of language X, is as fast as X. – Giorgio Apr 13 '12 at 22:11
  • I haven't had a chance to go over all the comments so someone may have mentioned this before; you should really check out Google Go! It's almost as fast as C, and in some ways it has some really welcome improvements! – W.K.S Jun 28 '13 at 13:38
  • 1
    Actually, the modern equivalent of the old ANSI-C everyone learned is the new C11 Standard C. It adds many modern features including thread support. See the O'Reilly book "21st Century C" before you start dismissing C as an 'old' language. This isn't your father's ANSI-C anymore... (...unless you're using Microsoft--they refuse to upgrade from the old, old ANSI standard) –  May 25 '13 at 21:42
  • C has an long history and widely supported in every regions. But I think you can try some concurrent programming language like **[erlang](http://www.erlang.org/about.html)**, which runs also fast on parallel computing. –  Dec 08 '09 at 06:58
  • 5
    \*cough\* Rust \*cough\* – Emil Laine Aug 04 '16 at 10:23
  • C18's string manipulation (`string.h`) is *still* terrible. In my opinnion implementing perfect string manipulation would make C a perfect language. Why do we have to wait *60 years* for a language to implement *human friendly* string manipulation? Fear of success? ---> https://www.youtube.com/watch?v=bjzITnc7PCE – 71GA Feb 09 '20 at 21:10
  • @Jason It is a good question but apparently lots of folks did not understand it and it triggered them to write answers that missed the point, making a noisy topic. I suspect this is the main reason for closure, just to stop the flood. 25 answers have been deleted, most of the ones left are still useless. – Martin Maat May 15 '20 at 04:44

6 Answers6

165

C is a very simple language, and it's because of this, along with its longevity, that's it's fast and optimized. It's also extraordinarily widely supported, in concerns with embedded environments, microprocessors, etc.

It's hard to beat a really simple and fast language. The only thing to improve upon a language like that is usability: decrease the time it takes to make similar, generic code, and make it easier to model with abstractions.

This is where C++ comes in. C++ can be just as fast as C. The thing is, C++ is a much more complex language, which means it definitely increases productivity; as long as people know how to use it. C++ and C are not almost the same language anymore.

Now, D was another step up. Same ability for fast code, optional garbage collection, etc., but it never caught on. Hopefully that changes, because it drops what plagues C++: backwards compatibility with C.

So to answer your question, "better" is a hard thing to judge. In terms of simplicity and speed, C is probably close to the best we could do. In terms of productivity versus simplicity, C++ is probably best we could do, though that opinion varies much more. Lastly, in terms of a fleshed-out and cleaned up language, with the speed and simplicity of C, D wins this context.

GManNickG
  • 1,020
  • 1
  • 9
  • 9
  • 36
    By "Simple" you mean "simple from a compilers POV, not the programmers POV". C is simple because it's basically assembly with statements and expressions. It's not simple the way Python is simple. – Marius Dec 08 '09 at 07:56
  • Correct. That's why it's so common in microcontrollers. – GManNickG Dec 08 '09 at 07:57
  • 17
    But to clarify, simple for the compiler *does* mean simple to pick up. Perhaps not simple to implement complicated ideas in. – GManNickG Dec 08 '09 at 08:01
  • 1
    The primary reason C++ caught on was due to compatibility with C. Dropping that, means that the designers have not understood that there is a major difference between a completely new language, and an incrementally improved language. The Java designers understood this as they chose C syntax for Java. –  Dec 08 '09 at 08:57
  • +1, My vote just gave you a well earned badge for this answer. – Tim Post Dec 08 '09 at 09:37
  • "In terms of productivity versus simplicity, C++ is probably best we could do" : How is C++ better than say c# using those criteria (I named c#, but I've got a few others in mind...) – Brann Dec 23 '09 at 13:10
  • 2
    You won't be writing an operating system in C#. (We're talking about systems programming languages, programming languages that compile to native assembly. anything you can do in any other language, you can do in C/C++/D, but not the other way.) – GManNickG Dec 23 '09 at 19:18
  • 1
    Not being backwards compatible is probably the very feature that caused D not to catch on. –  Feb 17 '10 at 11:58
  • 17
    For what its worth, OCaml produces highly optimized native code about as fast as C and C++, and code itself is as terse as Python. With a little polish, I think OCaml could match or beat C as the language of choice when you need to write code for maximum speed and minimum memory footprint. Objective-C also does a pretty good job, although its not always as fast as C, it gets the whole "C with objects" thing right in a way C++ never could and never will. – Juliet Mar 31 '10 at 13:18
  • 2
    Agreed with @Thorbjørn, backwards compatibility with C is why C++ caught on and D didn't. If we're willing to give that one up, there's no reason to settle for the incremental improvement that is D. We could go for far better languages that are completely out of the C family. As @Juliet says, OCaml could be a viable contender performance-wise. But so could a number of other languages, if compiler writers had spent as much time on them as they have on C or C++. Anyway, good answer, and +1 from me. – jalf Apr 10 '10 at 00:39
  • 1
    @jalf - I disagree. D's syntax is familiar enough so that a C or C++ programmer can pick it up easily and D can link to existing C libraries so that you don't lose the existing code base (C++ libraries are a whole other matter). – Ferruccio Dec 22 '10 at 14:49
  • 6
    @Ferruccio: Yes, but *every* language can link to C libraries. So if we're willing to settle for that, instead of actual source code compatibility, as C++ (more or less) offers, then we might as well pick a completely different language, say, Haskell or Python. The reason C++ caught on wasn't that it could *link* to C libraries. It was that it could *compile* C code. – jalf Dec 23 '10 at 09:13
  • +1 for "It's hard to beat a really simple and fast language" – Chani Apr 15 '11 at 07:32
  • D's development was controlled by a single company (Digital Mars), which had their own proprietary compiler. This could well have held back adoption early on. However more recently there are open-source compilers available. – ideasman42 Sep 04 '15 at 16:27
  • "C++ is a much more complex language, which means it definitely increases productivity": huh? Beyond a certain level, complexity will rather decrease productivity. In fact, most C++ programmers use only a subset of the language. In any case, I do not think that an increase in language complexity automatically causes an increase in productivity. – Giorgio Nov 25 '15 at 20:09
  • @Giorgio "as long as people know how to use it." follows that quote. If you're an expert in C++, you will write code faster than in C. I agree the sentence is a bit weird though, but also old enough for me to not edit. :) – GManNickG Nov 26 '15 at 00:38
65

There are languages faster than C.

For example, Fortran as already mentioned is doing very well because it has much more restricted aliasing language rules.

There are also experimental assembly like languages which are attacking C on the front where it is used as a high level assembler language for example compiler creation. Ever heard about C-- or Janus? But those two were killed by the LLVM project.

I would bet that APL or other mathematical languages will blow C out of the water in their special application domains as they have build in support for Vector processing units. This is something which is not possible for C (and guys: NO! Special optimized libraries with C linkage have nothing to do with C as a language).

Also CPU producers removed all stuff helping compiler writers in other languages - remember the tagged arithmetic assembler codes for making LISP implementation on SPARC fast? Gone with the wind.

And if you go away from micro benchmarks to application development then there are faster languages for application development. My personal example here is always SmartEiffel. It targets C but is using global system optimization which makes it faster then C in real world application development.

In this domain even a simple wrong or low level abstractions can kill the whole language performance. Because C does not offer high abstractions most people say it is a programming problem but it is not. For example look at the lack of generics. In C you will end up with slow implementations like the "qsort" library function which can be written a magnitude faster with generics (where the function call for key comparisons is eliminated).

Just compare a qsort call on a megabyte array of ints with a good hand written implementation which is using array access and the builtin '<' operator.

Mefitico
  • 101
  • 6
Lothar
  • 629
  • 5
  • 6
  • 10
    Very good comment. It is important to realize that some aspects of C language spec (like pointer aliasing rules) make it impossible to generate truly optimal machine code. Being a high-level assembler, C is not "the fastest", but merely "pretty fast". –  Dec 08 '09 at 09:00
  • 1
    Thanks i forgot to mention the impossibility to return multiple result values. Another low level aspect that i'm missing hard when using it as high level assembler. –  Dec 08 '09 at 11:47
  • Curious: I thought you couldn't have multiple return values? At least, in x86, you can only return one value from a subroutine, which is stored in ax? –  Dec 08 '09 at 15:22
  • 6
    Modern C, properly written, can encode the same aliasing assumptions as any other language, allowing the compiler to make the same optimizations. It's an important feature of the language that it also allows the programmer not to assume those requirements when they're not applicable. Your other points are spot on, so +1. – Stephen Canon Dec 08 '09 at 16:32
  • 2
    @Rascher: Thats right and there you see the influence of C on the CPU designers which always specify a CPU ABI. And multiple return values is something that just doesn't come to there mind even if the number of registers would not be a problem (SPARC, PowerPC, Itanium) –  Dec 08 '09 at 19:02
  • 14
    Pointer aliasing in C has been dealt with by `restrict` in C99 (10 years ago!). –  Dec 09 '09 at 00:01
  • @Pavel: Yes, and there's a lot of compilers out there that don't fully implement C99. It's unfortunate, but it does show how difficult it is to replace C. – David Thornley Dec 09 '09 at 15:00
  • IMHO this is the true answer – RCIX Dec 14 '09 at 09:35
  • 1
    @poundifdef People have been able to return a struct containing multiple values in the [C language](https://en.wikipedia.org/wiki/C_language) for decades. It's part of ANSI C, also called C89. (You could only return one value, in the earliest K&R C compilers). – David Cary Jul 22 '14 at 22:48
  • 1
    Sorry David, but the struct is a terrible hack, and nothing then a fanboy excuse. I'm sick of it. For example you can't apply them in a single expression as multiple parameter, assignment need additional code, you can't simply ignore one, you need struct definitons etc. pp. It is not the same as multiple return values. And while some compilers might be smart enough to even return the struct in multiple registers it usually does not happen. – Lothar Jul 29 '14 at 21:13
  • 1
    @StephenCanon: Is there any mechanism in C to tell a compiler that a global variable may safely be cached in a register across a call to an external function? Is there any mechanism in C to indicate that a write to `short*` might clobber a particular `int`, other than by using `memcpy` which would force the compiler to flush to memory everything that could alias and then reload it after? – supercat Aug 01 '15 at 23:09
  • No @supercat, memcpy does not have a memory fence. If you memcpy it into a global var you can't expect it to be visible to other threads. That it can't invalidate variables cached in registerers in upper stackframes is a no brainer. Therefore you need the global variable to be declared volatile which forces it out of every register. But it would hurt performance and still don't cache the multithreading issue. Does write to a volatile variable imply a memory fence operation? – Lothar Aug 02 '15 at 21:14
  • @Lothar: I wasn't talking about multi-thread scenarios. Under the Strict Aliasing Rule, following `uint32_t x = 0x12345678; uint16_t *p = (uint16_t*)&x; *p = 0xABCD;`, reading `x` will yield UB unless `x` is written (as a `uint32_t`) first. Using `uint16_t n=0xABCD; memcpy(&x, &n, sizeof n);` would modify `x` in a Implementation-Defined fashion (typically setting it to 0xABCD5678 or 0x1234ABCD, though other values would be possible). I didn't mean to imply that `memcpy` requires flushing anything that might be aliased by anything anywhere, but it does effectively require... – supercat Aug 02 '15 at 22:52
  • ...writing out any "dirty" cached values that could alias either operand, and invalidating any cached values that could alias the destination, except in the particular scenarios where the compiler can identify *exactly* what the source and destination are. – supercat Aug 02 '15 at 22:54
  • Regarding `qsort`. Last time I checked, even integer sorting with `std::sort` was less than twice as fast as with `qsort` - not "a magnitude". And disregarding the fact that you could always hand-roll a sorting implementation, and instanciate them for different types using whatever code generation (need not be macros), the `qsort` way actually wins big in most situations: A sort is very rarely the bottleneck. And qsort is truly generic (namely, in machine code). It avoids the machine code bloat that is C++ templates, so is much more cache-friendly. It's usually my first approach. – Jo So Apr 09 '18 at 22:06
36

Good question. I think languages succeed by finding a niche. It's important to note that there are plenty of newer languages that are better than C in their niches.

  • C was once widely used as an application language, and in that domain it has steadily lost ground to C++, Java, and recently all sorts of other languages (notably the dynamic languages).

  • C used to be a language for writing server code. The Web pushed an amazing variety of languages into that space--Perl, Java, Python, VBScript, VB.NET, Ruby, C#--and cases where C makes any kind of sense for server code are now few and far between.

  • C has been used for scientific computing, but it faces competition from domain-specific languages like Matlab and Mathematica, as well as libraries like SciPy. A lot of people who write code in this niche are not coders by trade and C is not a great fit for them.

But C's niche is system code. Operating system kernels. Drivers. Run-time libraries. It is so established in that space that even C++ is displacing it rather slowly.

C won back in the 1970s because of UNIX, because the competing languages were either too restrictive or too slow, and because C code was considered reasonably portable (lies, even then). But its biggest advantages today are unrelated, and stem mainly from decades of dominating its niche. There are good tools for C: optimizing compilers, kernel debuggers, effective static analysis to find bugs in driver code, etc. Almost every major platform defines a C ABI, and often it's the lingua franca for libraries. There's a pool of programmers who know how to code C--and who know what C's problems and pitfalls are.

Long-term, this niche isn't going away; and C has some problems. But it would still be extremely hard for any newcomer to compete.

Jason Orendorff
  • 419
  • 3
  • 5
  • 9
    C is still widely used for server code. There is not only the Web, most DNS, email, etc servers are written in C. Even for the Web, Apache is in C. –  Dec 08 '09 at 19:19
  • @bortzmeyer: Apache is pretty old though. I'm not saying it's not useful or has been superceded, it was just created when C was it and there weren't many good alternatives. – Macke Dec 08 '09 at 21:05
  • @Marcus, no, it was created on the Unix platform, and on Unix that means C. Especially in those days you had to distribute source as the binaries could not and cannot run across platforms. –  Apr 10 '10 at 06:57
  • 1
    I'm curious as to why you consider C "not a great fit" for scientific computing. Python is admittedly more pleasant to work in, but I've found C to be a solid alternative when faster code is needed and many of the possible alternatives (C++) not bringing a huge amount more to the table, unlike in other aspects of programming. – Fomite Nov 19 '11 at 03:37
  • 1
    Beyond that, the amount of stuff in SciPy/NumPy etc. that's *written* in C already makes it useful to know. – Fomite Nov 19 '11 at 03:37
  • 2
    @EpiGrad Maybe C is a solid alternative for you. But C has a super steep learning curve, especially for people who don't have a background in coding. In particular, sometimes it crashes, and if you're not a coder you have little hope of figuring it out. Mathematica makes a huge number of things easier to write and you end up with less code by factor of hundreds. And it doesn't crash. – Jason Orendorff Nov 21 '11 at 22:36
  • I find it curious that C has yet to provide any decent portable way of doing arithmetic with known-sized quantities. For example, is there any efficient way of multiplying two `uint32_t` values to get the bottom 32 bits of the result without risking Undedfined Behavior, without relying upon the size of `int` or casting to `uint64_t` [which seems absurd if what one wants is a 32-bit result]? Casting to `unsigned int` would fail if that type was less than 32 bits; casting to anything fixed-sized type smaller than 64 bits could fail if it was smaller than `int`. – supercat Feb 22 '14 at 16:38
  • I guess casting to `unsigned long` would be safe, and on some platforms might be more efficient than casting to `uint64_t`, but it still seems rather icky. I would expect code would more likely just expect the multiplication of two `uint32_t` values to work, but such expectation is not justified by the standard as written. – supercat Feb 22 '14 at 16:40
25

Paraphrasing a very good comment: There are not many different ways to make a language fast and "close to the machine" - C did it well, and there is hardly any room to improve upon that.

Original answer:

Fast to execute or fast to write stuff in?

Languages are not fast or slow to execute, specific implementations are. A languge can only be considered faster than others when it somehow makes it easier to have a fast implementations. Invariably, that means "close to the machine". But with machines getting faster exponentially, that has become progressively less interesting over time. Instead, ease and speed of development and portability have become much more important, so "better" has become to mean "away from the machine". Pretty much all efforts in language design have gone into that direction for the last 5 decades.

So there you are: closer to the machine and faster languages than C exist; they're those that came before C: Assembler, Fortran. Probably some forgotten ones.

Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
  • @michael - but there's still a market for super-lean, super-fast programming, especially with the onslaught of all these mobile devices... why is C still the best option for some of these devices, ie, why is there not another at-that-level language, like .NET-vs-Python-esque? – Jason Dec 08 '09 at 07:22
  • and i meant fast to execute... i understand the benefits of higher-level languages being faster to write in (i write in .net, ha) – Jason Dec 08 '09 at 07:23
  • 5
    Lisp. Slumbering but not forgotten! :) –  Dec 08 '09 at 07:28
  • 2
    @Jason: Question is, how many portable assemblers do you need? C is well known and it's very hard to write a language with a faster implementation, so why bother? In suit-speak, there's no requirement, no market, no motivation. –  Dec 08 '09 at 07:31
  • 4
    @ Michael, apologies for comment-jacking your answer. The reason there is more in the terrain of python/ruby/java etc is that once you stop trying for the most efficient possible language you get a lot more options as to which features to prioritize, and every approach can yield a new language. There are far fewer ways to write the fastest possible language. –  Dec 08 '09 at 07:35
  • @carl - that's a pretty good point. i didn't think of it in terms of certain higher-level languages highlighting specific features to provide different options – Jason Dec 08 '09 at 07:40
  • @Jason: No there is no market. At least there is no market for tool developers to sell there tools and get a ROI. There are free C implementations for all platforms and the people are not spending money for development of languages which are only a little bit faster and better. And even an ARM cpu runs so fast these days, it doesn't make sense to focus on this level. –  Dec 08 '09 at 07:54
  • 1
    -1 for "and there is hardly any room to improve upon that" - there is *plenty* of room to improve on C/C++ without affecting performance. – BlueRaja - Danny Pflughoeft Mar 31 '10 at 13:13
  • In the end even 5% speed increase matters when you are writting applications for banking... The one that is the fastest buys all the stocks... This is where C shines... – 71GA Feb 10 '20 at 07:09
  • 11 years later and speed is becoming an issue again because lazy developers can no longer rely on "easy" languages to get non-trivial stuff done. This will become even more relevant over time. Modern compilers are slow, web stuff is slow/bloated, big data access is slow, browsers are slow/bloated, etc. This is why we now have plethora of new C replacement hopefuls competing for market space. It would have better if this new trend started a decade ago; instead we just ended a decade of probably the worst performing code ever written because "CPUs are fast, so why bother doing our job?" – SO_fix_the_vote_sorting_bug May 14 '21 at 17:49
22

Fortran is faster than C for numerical tasks because of the way it handles memory references (C pointers are more difficult to optimize). The heavyweight numeric libraries at the base of things like Matlab and Numpy are still written in Fortran.

On the other hand, C++ can be just as fast as C, but has many more advanced programming features. It's a much newer language, from the mid 80-s.

  • 1
    And C++ is still being updated. – GManNickG Dec 08 '09 at 06:30
  • 5
    @GMan: so is C. –  Dec 08 '09 at 09:16
  • Really? Last one I know of is C99. Is there a new standard coming out? – GManNickG Dec 08 '09 at 09:34
  • 7
    C1X (http://en.wikipedia.org/wiki/C1X) –  Dec 08 '09 at 15:12
  • 3
    Correct me if I'm wrong, but wouldn't a C99 `restrict` pointer have the same aliasing semantics is Fortran? And what else is there that makes any difference? –  Dec 09 '09 at 00:02
  • 1
    @Pavel: As far as aliasing is concerned, yes. Fortran also has looser floating-point semantics -- the default is somewhat akin to `-ffast-math`, but it's not obvious that that's a good thing. – Stephen Canon Dec 09 '09 at 05:42
  • 10
    I think the idea that Fortran is faster than C is somewhat myth, depending on what's being coded and who's doing it. The reason heavyweight numeric libraries are in Fortran is not because Fortran is faster, but because the routines were originally coded in Fortran and few people have the nerve or need to re-write it. The small number of math-gurus who write and vet these algorithms are happy in Fortran and see no need to change, especially since they imagine Fortran is faster. – Mike Dunlavey Jan 26 '10 at 15:07
  • @mike-dunlavey Myth? No. Overblown? A little. There's simply a good handful of algorithms that Fortran compilers excel at. A splash of Fortran is slightly more convenient than dropping to assembly. –  Feb 04 '10 at 03:14
  • @Pestilence: I've heard that, but I haven't seen it. I've seen plenty of C and Fortran, including lately. I haven't seen any case where the ASM that Fortran generates could not be equaled by C in the hands of a competent programmer. Maybe it exists, but I haven't seen it. – Mike Dunlavey Feb 04 '10 at 03:25
  • 1
    I recently attempted this. I was attempting to move a bunch of fortran coded seismic migration and processing (http://en.wikipedia.org/wiki/Seismic_migration) routines out of fortran only to discover I could never optimise the C code to on par with Fortran speed wise. I kept the fortran. – Montdidier Jan 14 '15 at 08:05
16

What the heck, I'll chime in with my $0.02.

In many instances there is a real or perceived difference between "systems" languages and higher level languages. I'll ignore most "higher level" languages, since nobody (at least not many) will argue that for many tasks, languages like Python, Ruby, etc. are simpler to work in.

C was designed to be a systems language, meaning it was designed as the language in which the Unix operating system was written in. As such, it was designed to be simple, powerful, and fast. A simple language gains power by means that non-systems-programmers often consider dangerous: pointers, manual memory management, etc. As has already been mentioned, C is quite simple. K&R is the smallest book on my programming shelf by far (not counting O'Reilly Pocket References) and it's only marginally "bigger" than my Ruby Pocket Reference. C is quite powerful. If you need to talk to hardware, manually check and twiddle with memory, etc. C has the capability.

From a programmer's perspective, however, C is not so simple. Speed and power come at the price of manual memory management and not much OOP support built in to the language. C++ (not my favorite language) is much simpler from a programmer's perspective, but much less simple from a compiler's perspective. Objective-C (possibly my favorite language) has the same tradeoff, with slight lean in the direction of keeping the language simple (garbage collection is a newcomer to Objective-C, for example). But since the computing world as many of us know it was written in C, it's difficult for newer, more-complicated but "easier" languages to gain widespread adoption.

In some cases, especially when the current "standard" is as "good enough" as C is, there's simply not a lot of incentive for something "better" (C++, Objective-C, D etc.) to gain traction, when there is even enough incentive to create something "better".

alesplin
  • 181
  • 1
  • 5