tags:

views:

3788

answers:

30

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".

+13  A: 

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.

zaharpopov
And C++ is still being updated.
GMan
@GMan: so is C.
Porges
Really? Last one I know of is C99. Is there a new standard coming out?
GMan
C1X (http://en.wikipedia.org/wiki/C1X)
Snarfblam
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?
Pavel Minaev
@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
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
@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.
Pestilence
@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
+7  A: 

As others have questioned: Have you completely forgotten about c++? Also, lately I have been experimenting with D. Have a look at it.

Alex
C++ is not an alternative to C... it's almost like an upgrade. I'm talking about something completely different than C, like Python is to Java or something of that nature.
Jason
C++ "leaves" the machine, in that all the features it adds are abstractions away from it. i don't believe you can consider C++ to be an machine-level replacement for C at all.
Matt Joiner
C++ is C with object orientation bolted on. This is bad because the programmer's still responsible for a lot of low level stuff, a tremendous potential for errors and a productivity sink. It's good because C++ is one of few OO languages where you can write OO code that has 0 overhead over pure C code.
Carl Smotricz
C++ has implemented some of it's features in very silly ways (namespaces, overloading), which is why it's uptake has perhaps been slower than one might expect.Of course C has many problems too, however when it came out it was the lesser-problemed language.
Reality
+6  A: 

Computers have gone faster and programmers have gone lazy. So not many people bother making something faster than C; or; code in C.

Salman A
+92  A: 

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.

GMan
thank you for your well-thought-out answer
Jason
Withdrawing my answer because yours says the same things, and better. +1.
Carl Smotricz
props for pointing out why C++ is not an obvious replacement for C
Matt Joiner
why haven't you marked this guy as the answer? +1
Paul
Well I'd prefer to have my response marked as the answer, not me :)
GMan
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
Correct. That's why it's so common in microcontrollers.
GMan
But to clarify, simple for the compiler *does* mean simple to pick up. Perhaps not simple to implement complicated ideas in.
GMan
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.
Thorbjørn Ravn Andersen
+1, My vote just gave you a well earned badge for this answer.
Tim Post
"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
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.)
GMan
Not being backwards compatible is probably the very feature that caused D not to catch on.
Thorbjørn Ravn Andersen
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
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
+10  A: 

In my opinion, C is a basic language. It can control bit, like Assembler! On the other hand, C has a good structure, such as "if...else...", "switch", "for" and so on. As well as you could even create your own functions.

If a language is prime (closed to hardware), and is also easy to use, specially not complicated (there aren't gaudy packages). Then it's popular.

There isn't a best language, but a fit one.

sirius
The typical term for "close to hardware" is "low-level." C is often referred to as a middle-level language.
Jason
Jason, you're right. Maybe "be friendly to hardware" or "efficient with hardware" is better.
sirius
@sirius, C was designed to write a portable version of Unix, in other words a portable assembly language.
Thorbjørn Ravn Andersen
A: 

Wow, am I going to be the one sticking up for C? Really? Look, I'm a pascal nut from way back, so I don't like C, it lets you do too many dangerous things, and too many obscure things, and you can't clear your throat without a pointer. But even I know, that all that means it is perfectly situated as a high level assembler. Nothing else comes close. Period. So your problem isn't that you want something better than C, it's that you don't want C.

Ken Lange
This has nothing to do with what I want or don't want. I don't even program in C (although it was what I was taught in school). I was just curious about the options at hand.
Jason
Pascal is the most fascistic, paternalistic, communistic programming language I have ever used and hated. It treats the programmer as an idiot and won't let you do anything useful.
Blessed Geek
Facscitic...., communistic... like down voting someone's comments because of your personal emotional biases, instead of the intellectual content.
Ken Lange
Any useful dialect of Pascal has pointers and allow you to blow things up. Just like C...
Thorbjørn Ravn Andersen
+1  A: 

C has an long history and widely supported in every regions.

But I think you can try some concurrent programming language like erlang, which runs also fast on parallel computing.

mmin
+6  A: 

Your choice of tool is going to be dependent on the task at hand. I would not write a kernel in C++ just as much as I would shy away from writing a monte carlo simulation in C.

I think it would be extremely difficult to justify a single 'uni language' that boasted the features of C/C++/Fortran/CAML/OCAML and others selectively, depending upon compilation. Its more common sense than 'consensus thinking' to just use what exists and best fits the need.

There is also the issue of the language meaning the 'same' thing to vastly different groups of people, which is one of the reasons you only see C and Assembly in the Linux kernel.

Usually, the 'right and correct' tool for the job also implies accepted and immutable versions of a single specification and standard. While new languages like Go do promise awesome flexibility with great performance, its going to be a while before you see them used on Wall Street or in a Boeing passenger jet.

Tim Post
+1 thanks for this, tim.
Jason
+10  A: 

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
@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
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
Lisp. Slumbering but not forgotten! :)
Carl Smotricz
@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.
Carl Smotricz
@ 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.
Carl Smotricz
@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
@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.
Lothar
-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
+4  A: 

A program written in C is only as fast as the compiler makes it. One of the reasons that C is still around is a historic one - there is a lot of momentum in brains involved in C compiler design.

But then again just about the only thing you could do to make C better is to add garbage collection. This is certainly not acceptable when working close to the metal and needing full control over your memory lifetime and your threads.

One some level you are right, there could be things that will make C suck less - i.e. not having to typedef struct and better variable scoping, but those are pretty much in the syntactic sugar category.

Igor Zevaka
You never have to typedef a struct. There is nothing wrong with using the word 'struct' in your declarations.
William Pursell
Of course you don't but it's so much more awkward.
Igor Zevaka
Or use C99. No need for `typedef struc`t anymore
drhirsch
Pestilence
+2  A: 

C can do that. Other languages is for abstraction. They are better. But, you can do everything, using c. Use it if you like. I use it when I need and don't asking why.

Vasiliy Stavenko
+35  A: 

There are faster than C languages.

There are faster languages 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 assember language for example compiler creation. Ever heared 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 there 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.

Lothar
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".
Constantin
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.
Lothar
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?
rascher
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
@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)
Lothar
Pointer aliasing in C has been dealt with by `restrict` in C99 (10 years ago!).
Pavel Minaev
@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
IMHO this is the true answer
RCIX
+1  A: 

Closest is microcode. VHDL you may want research since supervisors won't like microcode. Most interesting new I tried is vvvv

LarsOn
VHDL is for designing hardware, not running code close to the hardware, infact it tends to be pretty slow to simulate VHDL
jk
VHDL is not really code in the traditional sense. It's a hardware description language, meaning that you describe the way the hardware will operate and it will be synthesized down to gates and wires.
Bob Somers
VHDL designed my pen, pencil and paper I use for designing hardware. good languages
LarsOn
VHDL is software in hardware. It's the lowest level you can get. NVidia codes their GPU in Verilog after all.
Pestilence
+3  A: 

C++ is pretty much a superset of C - you can write a C program and pass it through a C++ compiler to get the same code. However if you use all the features of C++ then it does become a much more complex language and you move further away from the metal with a corresponding loss of performance, but it is possible to be use a selective subset of C++ to make it an enhanced C. Part of the attraction of C++ is it gives that choice to the programmer.

Others have mentioned D. There is also Google Go which was announced a few weeks ago, which they are touting as a modern alternative to C. I have not tried it so cannot comment on it, but the feature set looks interesting especially for concurrent programs - this is an area where both C and C++ are lacking.

Dave Kirby
+21  A: 

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
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.
bortzmeyer
@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.
Marcus Lindblom
@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.
Thorbjørn Ravn Andersen
+5  A: 

I'd say that C mirrors how the CPU works pretty good. Not that each and every machine instructions is mirrored, but rather the basic features are there, you have functions and a stack. There are also the possibility to add machine instructions with the asm word in C. Together these things make it a good start to write an operating system in, and when that has been done you will have a base set of functions in libraries to use when creating programs to run on the system. From these base libraries one can create standardized libraries as posix.

As an example one can look at Linux. Linux is the kernel, the operating system that makes a system tick. On top of this there are many layers of utility libraries making use of the features available in the kernel. On a Linux system this often comes from the GNU project.

As a result of all this all other languages still need to be interfaced to the system. Using C you are closer to use these features.

As an example, if you really want a fast http server there are at least one that is built into the kernel http://www.fenrus.demon.nl I can't imagine trying to do that in any other language than C

As an example of another system not suited for the C language I can mention the old Xerox Lisp Machines which even had the basic Lisp features implemented in the CPU. See wikipedia info. But that looks more like an experiment.

epatel
+7  A: 

C intentionally models a CPU very closely. Hence you can create very tight code which maps very well to the target CPU.

Just because things have been thought of long time ago, does not mean that the thoughts outdate if the basic premises are the same. Do do not try to build a better mouse trap.

Thorbjørn Ravn Andersen
I think over this long time a co-evolution of C and CPUs has happened. After C had become the fundament of almost every operating system, CPU desginers started to model their CPUs to match C very closely.
drhirsch
You essentially describe RISC - http://en.wikipedia.org/wiki/Reduced_instruction_set_computer
Thorbjørn Ravn Andersen
I believe C *models* how CPUs worked at the time of UNIX conception. And it's been a jolly good model you could keep running seamlessly with *transparent* layers until the *recent*... Core Duo advent.
ZJR
ZJR, I believe your observation is correct. If multi-cores had been common in the 70's C would have reflected that.
Thorbjørn Ravn Andersen
Pestilence
@Pestilence, C models "enough" of a cpu that Unix could be compiled for it. The Linux kernel is written in C, except for a few platform specific things, for the same reason.
Thorbjørn Ravn Andersen
@thorbjorn-ravn-andersen Unix was first written in PDP assembly language. It was *rewritten* in C for portability... the same reason Linux is written in C. Many operating systems were originally written in non-C languages and some even in C++. The convergence is only relatively recent.
Pestilence
@Pestilense, yes. C was designed to _port_ an operating system to other platforms and reflect that.
Thorbjørn Ravn Andersen
+4  A: 

I don't think C would have caught on so well, had it not been for UNIX. C is not the most efficient thing to parse & compile. It's awful in that respect, actually.

Not everyone jumped on the C bandwagon. Apple, for instance, started Macintosh OS in Pascal. In fact, there was a bit of Pascal in early versions of Windows, IIRC.

I really think the battle between the two could have gone either way. Both derive from ALGOL, which is the source of the whole structured programming revolution (loops, if statements, etc.)

Up until the mid 90's, Pascal still had a strong following. Lots of commercial apps continue to be written in it, but more for legacy reasons than practicality. Now that universities have stopped teaching it, it's destined for obscurity.

Pestilence
Well the Wirth languages suffer from the same problem: The langauge designer thought that languages should be very simple. This is IMHO a very stupid and wrong mistakes. And thats why Pascal and Oberon vanished. At least a Modula-3 implementation is still alive.But all of this was not the question. Was Pascal as fast as C - no, never
Lothar
I think "Pascal vs C" is an interesting topic as in C the *calling conversion* is that the caller is responsible to remove the parameters from the stack where as in Pascal it's the callee's responsibility. An result of this is that in C one can have variable amount of parameters.
epatel
...and, when writing device drivers which can be activated *anytime* ie by an interrupt there is a pascal keyword for C to change the calling convention (spell checker mistake above) for a function.
epatel
I must disagree about the performance, Lothar. I always profiled my Pascal code and it was very close to C speed (Borland). The difference isn't too unlike the output of GCC versus Intel's compiler. The problem lays more with the compiler's optimizer than the language itself.That said, Object Pascal will always be faster than C++ with RTTI and exception handling turned on. The stock containers, like THashMap, are always faster than STL. Still, the difference is negligible at the end of the day.
Pestilence
Wirths languages was made for teaching and learning. It was an added benefit they could be put to industrial use. I believe Java has completely overtook the "learn to program" niche.
Thorbjørn Ravn Andersen
+5  A: 

Pascal is about as fast as C. Missing libraries aside, there is hardly anything you can do in C but not in Pascal.

ammoQ
In pascal you have another calling convention which can be declared for a function in C with the keyword "pascal". Have left a comment about this @Pestilence answer
epatel
epatel: True, but it only helps when you have a chance to recompile the C function...
ammoQ
Please call it "Object Pascal" or else you reference archaic old Turbo Pascal. (At least in people's minds.) Object Pascal is just about as fast as C, has pointers and OO programming, and it's quite so hash on the eyes.
The Wicked Flea
I had the archaic old Turbo Pascal in mind ;-)
ammoQ
@ammoQ: *everybody does* and that's why *everybody hates Pascal* and religious wars ensue.
ZJR
Pestilence
+7  A: 

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
+1 thanks, this is a good answer
Jason
+2  A: 

Without saying what has already been said about C's advantages...

As long as there are still millions of lines of legacy code out there that need to be used, C will remain. I do believe many languages can perform with satisfactory speed -- and face it, probably not even half of us need to really squeeze every speed we can get -- especially with today's technology where memory too is not much of concern to the majority of us.

C just happens to be available (and good) back then.

SyaZ
+1  A: 

Assembler is the fastest language. There is no any language except asm that would be faster than C, because it is not needed. What will you do with another C language? Which is exactly as C but with different syntax? If you want speed at all cost - you use asm. If you want a bit more comfortable programming, you take C. If you need complex constructions, classes, OOP and fast development, you take C++, C#, Delphi, etc. There is no another language as fast as C, just because there is C.

Well a C which allows multiple return values could be faster then current C and support for vector units are also missing seriously at the language level. And what about computed gotos or exceptions instead of very slow (setjmp and longjmp). And for multithreaded programming a definition of the memory model. The more i type the more i realize that we need an improved C language.
Lothar
*Seamless parallelization* is the thing C lacks (and can't get) that could make it *faster* in this *octuple-core* world. I kinda feel **erlang** fandom is getting louder and louder and *even from a C partisan perspective* I see they may have a point.
ZJR
+1  A: 

Languages you use depend on what you want to do, but also on their acceptance. Java is way simpler to program some things, but it's way slower because it uses the JVM but especially because it's higher level, so you don't have the same control over the way your hardware is used. Assembly is faster than C, but C is way easier to use :-P. The amount of control you have it's pretty important.

IN AI Lisp is very popular, but it's still coping to be as fast as other languages. However it's syntax is appropriate for AI work. C++ became popular in games because it's OO-oriented, is, for now, faster than Java and C#, and the most popular game engines are written in that language.

With the advent of the OO-programming languages, I think people forgot or stopped trying to make competition for the lower level languages. That's also because there's nothing wrong with C. Of course C has some disadvantages, especially for it's use of pointers which may cause memory faults that are hard to test and debug. Some recent projects aim at solving C's problems, but I think they're not popular because C doesn't have that many problems :-P and also, there's already a large number of applications that were developed in C.

webdreamer
+8  A: 

Check out Go: I think Google is thinking the same way you are.

C has been around for a long time because it is a decent language and it just so happens it is used on a lot of projects, therefore it lives as long as those projects do.

Chap
Go is certainly not faster than C. Not even close. Maybe it will be in time, but for now it isn't.
ryeguy
It's not faster than C, sure, but I think that's Chap's point: that Google is trying to make a well designed competitor to C that is nearly as fast, or faster.
The Wicked Flea
A language that requires garbage collection is not a competitor to C.
Pavel Minaev
@Pavel: I'm sure that 99% of programs currently written in C will be better off with garbage collection than manual memory management - the remaining 1% can still be written in C.
Rene Saarsoo
Well phrased: «it lives as long as those projects do». Let me remark those *projects* are **every operating system on the market today**. Then again we don't market operating systems anymore, we ship them with hardware products... there's room for change.
ZJR
+3  A: 

There is a lighter (even closer to the CPU) implementation of C,called "Sphinx C--" ( C minus minus ).

Here's some text quoted from the Sphinx C-- site:

Sphinx C-- is a programming language that combines C and assembly language. It runs at the DOS commandline and can generate applications, library files and drivers for 16-bit and 32-bit DOS, 32-bit MS Windows, and MenuetOS, and probably more. In this page I introduce C-- and how it can be used for MenuetOS and Windows.

Why write apps in C--? In a nutshell, C-- has low-level features, placing it somewhere between C and assembly. Sometimes a high-level language such as C can be very frustrating when you want to write code that accesses the underlying hardware architecture, or utilises the architecture for optimum efficiency. For example, I have used a C compiler called MACC to write applications for MenuetOS, and to call a software-interrupt routine, passing parameters via registers, involves first pushing the parameters onto the stack, calling an inline asm routine which transfers them to registers then calls the interrupt -- which is very inefficient. Often a C compiler places frustrating restrictions on in-line assembly code -- for example, MACC will only allow asm code outside a C function. C-- releases you from the straight-jacket, into a world of unfettered coding.

See at http://www.goosee.com/cmm/

Hernán
+2  A: 

Everyone's answers (for the most part) are correct, so I'll just try expanding on them.

The closer you get to the machine, the more room for optimization you have. If you are programming in C (vs C++), you are using what would be called a lower-level language and therefore would be closer to machine language. In the same manner, you could program everything in assembler and make micro-optimizations while you develop, with small (very very small) enhancements to already simple functions.

Then again, if you build the machine that uses the assembly language, you have even more room for improvements, which all higher level languages (at this point everything) can benefit from by some transitive property.

I have programmed in assembly languages and could easily argue that they are "better" than C at their functions, even though creating simple programs with them could take forever and then some. The advantage that each new iteration of language brings about is reduced development time, and perhaps some execution speed. If you want a faster program, look toward the hardware.

Norla
Disagree. Object oriented Assembly is quite rapid to develop with. No one seems to appreciate just how bare metal C really is. Assembly isn't *that* big of a jump. No?
Pestilence
Quite rapid with respect to what though? I'm currently using C#, and I doubt quite highly that even the best object-oriented assembly would even be in C#'s rear-view mirror in terms of rapidity.
Norla
+5  A: 

The fundamental reasons here is that C is generally good enough, and is well established.

There are a whole lot of things I'd change about C if I were to do it over. The switch statement is awkward and very error-prone. It's very difficult to parse, compared to modern languages. The string libraries are ill-designed. The operator precedence is badly done. On the other hand, people and compilers have adapted to these, and therefore C is generally very usable.

There's also millions, perhaps billions, of lines of basic system code written in C. Changing to another language would mean moving away from all that. There's real advantages to maintaining a codebase in one language, and real disadvantages in rewriting immense amounts of real-world code.

For that reason, I don't expect to see a real replacement for a long time.

David Thornley
It's almost word-for-word what I would have written if I saw this question earlier :) both the list of things that are wrong with C, and the explanation as to why they don't really matter anyway, and no replacement is in sight.
Pavel Minaev
More to that: real world code has security issues. That where already *handled, fixed and tested again* on **huge** user bases. That's an enormous deal in writing new code in a new language out of thin air.
ZJR
+1  A: 

C has the power and flexibility of assembly language, while still offering the clarity and maintainability of assembly language.

drhirsch
Since when has assembly been clear? +1 for that :D
RCIX
+2  A: 

One reason that C is still popular is library development. Many programming languages allow you to link to C libraries and call C functions. It's easy to add this feature because C's object file format is pretty simple and C data types and functions are pretty easy to model.

It a chicken and egg situation. There are many C libraries, so new languages support calling C functions. Because many languages do this, new libraries are more likely to be written in C so that they can be used from many languages.

Harold L
A: 

This is from memory...The history of C came about during the early 1970's when Ken Thompson and Dennis Ritchie were bored playing (was it Lander? for the PDP-10). At the time, Bell Labs, wanted to bring over the timesharing system across to the newer PDP system, called MULTICS, which was written in machine code. Dennis and Ken, played about with different language concepts, and coined the first C program by borrowing semantic bits from the BCPL language (incidentally, that was where the notion of *p++ and *--p came from, the actual machine instruction to do the equivalent of the pointer increment...)

So they used the new language (it underwent a few iterations, BCPL -> B -> C) to develop the system which was now Unix, hence the close ties and history behind it, this was in 1970, the K&R C language became official around 1972, before it got ANSI'd and ISO'd around the early 1980's.

Hence, that is why, it is said, C is closer to the metal, as the compiler took care of the incrementing/decrementing of the pointers (byte = 1, int = 2 and so on) as the job to port and embellish MULTICS into UNIX took less time as it was written in a language that was close to assembler.

Furthermore, this would explain why there is a Unix epoch time, 1/1/1970 and hence date/time manipulations were based by offsetting a positive number (in seconds if my memory serves me correct) to the epoch time to get the relevant date/time by using the said number as a parameter.

Because, it got ANSI'd and ISO'd, the popularity of the language took off and sky-rocketed because it was portable, it can run on many platforms.

DOS, OS/2, IBM's DB2, Borland's Sidekick, Lotus 123, QEMM, Duke Nukum, Commander Keen, GW-BASIC to name but a few, were all written in C.

Hope this helps, Best regards, Tom.

tommieb75