Is the C programming language still used?

  • I am a C# programmer, and most of my development is for websites along with a few Windows applications. As far as C goes, I haven't used it in a long time, as there was no need to. It came to me as a surprise when one of my friends said that she needs to learn C for testing jobs, while I was helping her learn C#.

    I figured that someone would only learn C for testing if there is development being done in C. From my knowledge, all development related to COM and hardware design is also done in C++. Therefore, learning C doesn't make sense if you need to use C++. I also don't believe in historic significance, so why waste time and money in learning C?

    Is C still used in any kind of new software development or anything else?

    Have you ever seen a C++ compiler for PICs?

    Generally for embedded system C is still widely used. This question gives some other example. The Tiobe index, which attempts to classify language by *popularity* / *usage*, consistently puts C in the first places.

    check out, especially the graphs from Freshmeat and Google Code. It shows that C still is way ahead. C is still popular on systems where you need to be get close to the metal (ie embedded system) and performance hungry applications.

    All are great answers and have added great value to the question. Thanks

    I am bit confused. All answers provide a one or two good points. Please vote for the ones you like. I will mark the most voted answer as the approved one as i can't judge which one is more better than the other.

    Am I the only who is sad that somebody would equate learning with wasting time and money?

    @Jetti , i second you as i keep on touching new things every day. The essence of question was not this what you take out of it. You can edit the post.

    @Pankaj Upadhyay - It isn't just you, I've seen it a lot on this site and on others. Also, I figured it was mostly just a poor wording of what you really wanted to express.

    Ya dats the case. Actually its the way my friend was putting, so i mugged up the words. While learning C#, she said she wants to go in C testing jobs so learning C# is a waste. Therefore i made the mistake of referring C in the same way.

    while not the best or most reliable site on earth, check out

    "*In my knowledge, all the development related to COM and hardware design are also done in C++*" - Sounds to me like you don't actually do any hardware interface design.

    Veracity is new development, and being done in C. "We chose to write it in plain old C to give us flexibility in porting to more exotic platforms in the future."

    @Ed S. : +1, To be honest, post 6 hours asking this question, i feel the same. Actually I never used C and neither done any hardware interface development. Therefore, in my own small world, i thought C is a legacy language and that's it. But now, I am astonished to learn its the most widely used language still, keeping java aside.

    Some JVMs are written in C as well, HotSpot is mostly C++.

    C is a dead language. People haven't used it since the mid 60's for anything serious other than academia, and even then, Fortran rules that world.

    A comment that isn't getting much attention on this thread is that each tool has a general purpose. Higher-level languages are great for some things, and not others. Same with when you go to slightly lower-level languages. Just because you haven't found a purpose for C doesn't mean it isn't heavily in use elsewhere. Likewise, I can name a a bunch of engineers who hate this "overly abstracted crap" used on a daily basis to churn out the applications that keep entire industries alive.

    Portability. Do a list of every system you think will run C code and then a similar list for every other language you like. If you came up with the same answer as me then the conclusion is yes.

    I use it almost every day developing for iPad/iPhone. Many libraries are written in C and don't have an Objective-C equivalent. So yes, it is still used, and by one of the newest device on market. With C, you can program lots of embedded systems, it's small and handy, and probably will be around for many years to come (aka you are not wasting time nor money learning it)

    I can't believe no one raised up the most important point (IMHO), obvius... =P ...throwing an answer..

    @SK-logic: that's besides the point but yes, there are C++ compilers for PICs !

    The minus 1 is for asking a question that is answered by the wikipedia article on C.

    People forget that the fancy higher level languages that we all love are often implemented in C.

    "I also don't believe in historic significance, so why waste time and money in learning C?": Nobody forces you to learn C if you do not find it useful, and the fact that there are plenty of developers, also young ones, who still use it , should be enough of a proof without the need to ask here. It seems you have posted this question to challenge people to convince you of the contrary, and possibly starting a flame war.

    @ThomasEding Dead language? You certainly have a very limited knowledge of programming languages if you consider C a dead language.

    @JesperE I think Thomas was displaying sarcasm when he wrote C is dead 18 months ago ;)

    Quite possible, but how can we tell?

    Really? All legacy system I can ever think of either uses C completely or under workshare with ADA, FORTRAN, etc. You are C# which is practically Microsoft's answer to Java.

    Funny enough, another person is quite interested in establishing that C/C++ is not a HLL here.

    @hagubear i am not really sure as to why you think this question is funny or doesn't make sense.

    A fair bit more than C#, that's for sure.

    Linux & embedded is where C rules. I love C but the libraries are abysmal b/c they all have the most minimal degree of abstraction (due to the lack of classes, generics, and overloading). But even w/ all that good stuff (i.e. C++) you still come across libraries and frameworks like Boost, QT, COM, and ATL where there is a greater degree of abstraction but at the cost of complexity. C# reduces the complexity by removing pointers, using GC, using attributes instead of template metaprogramming, etc. This results in C# having better libraries than C or C++. Also C# is open source now!

    C is traditionally portable assembler. This role is being taken over by Javascript.

  • sbi

    sbi Correct answer

    9 years ago

    C has the advantage that it is a relatively small language, which makes it easy to implement a C compiler (whereas a C++ compiler is a monster to write), and makes it easier to learn the language. Also see the TIOBE index, according to which C slightly ahead of C++.

    In (IMO) decreasing order of justification, C is still used a lot for

    • Embedded stuff
      It's way easier to port a C compiler to a small platform than it is to port a C++ compiler. Also, C advocates claim that C++ "does too much behind their backs". However, IMO that's FUD.

    • Systems programming
      Again, that's usually due to claims that it is easier to "know what the compiler is doing". However, many embedded programs would benefit from, e.g., templates and other C++ key features.

    • Open source software
      That's mostly an attitude problem, though: OSS has always preferred C over C++ (whereas it's the opposite in large parts of the industry). Torvalds' irrational hatred might actually be the most important reason for this on Linux.

    It's more history than attitude. Many of what you might consider the "core" open source packages were originally developed when C++ wasn't as widely available as it is now and resources were still scarce.

    @Blrfl: Linux turned 20 years today. 20 years ago we did have C++, although I agree that C++ without smart pointers and STL looks bleak from today's POV.

    Hmm.. building a C compiler is deceptively complex. Not like a C++ compiler of course; but C isn't as simple to implement as some make it out to be. (E.g. Pascal is a simpler language to implement)

    @sbi: Most of what I consider the core stuff (GCC, bash, tcsh, Emacs, X perl, screen and a very, very long list of others) was developed before Linux existed. You won't find much of anything in that category of software that was developed in C++ during the 1980s. I was there, and it just wasn't happening.

    The TIOBE index is a joke. Search engine hits are meaningless.

    @Blrfl: Actually I know that (and therefore my comment did not explicitly disagree with you). However, there have been a few OSS projects started since, and many of them still stick to C rather than using C++, often for rather irrational reasons.

    A basic working C compiler, as opposed to a useful optimizing one, is rather simple. See `pcc` or even `tinycc` for examples...

    @R, a heavily optimising compiler is easy to build now, with such a great toolchain as LLVM.

    Why would an embedded program benefit from templates? They generally blow out binary size and were specifically _removed_ from Embedded C++.

    @Sedate: That templates _generally_ cause code bloat is a myth, coming from the times of ancient C++ compilers. Modern compilers will fold identical template instances. OTOH, templates allow template meta-programming, which executes code at compile-time, rather than run-time, resulting in _less_ code being generated. Also, they make for much safer programs (less casting), something that's often very important in the embedded domain. EC++ has been bashed to death by C++ experts over (among other things) the sheer stupidity of throwing out templates.

    @sbi: If you can find "modern compilers" for anything other than the most common AVR and PIC chips, I'll be very impressed! I'm well aware that great improvements have been made in "consumer-level" compilers (for want of a better word), but these do not often translate to compilers for small micros.

    @Sedate: I have no experience in this field, but from what I understood GCC is available on many embedded platforms, and it comes with quite a good C++ compiler. But even if it's not, then there's the old chicken-and-egg problem: Why should vendors put money into licensing a good compiler when their users still believe in old FUD statements, don't even _know_ about C++' features, and do not plan to learn about them? (EDG licenses the best front end money can buy, Comeau, based on EDG, ports their compiler to any platform for little money, and the GCC/Apple deal could be copied by others, too.)

    This compiler seems to support some advanced feature of C++: I haven't touched PIC embedded programming for years now, but I remember finding another C++ compiler back then for it (I think it was IAR) and that's what got me started on C++ dev on Linux first, then Windows.

    Torvalds hatred is actually pretty rational! The things that turn him off C++ are real turn offs for anyone who just wants to develop efficient, portable, multi-platofrm software.

    @James: You mean things like efficient abstractions, generic programming and type-safety? Yeah, who'd want that.

    @James: Might I kindly point you at this comment, where there's a link to a posting in which someone earnestly takes Linus' rant as if it was something intelligible, and takes it apart sentence by sentence. Write a reply to that that's at least half as intelligent as that one and post the link here. Or go back to the cave you came from, and keep cargo-culting.

    @sbi -- The problem is every argument you can make for using C++ rather than C, there is a better argument for using a higher level language like Java, Scheme , or Python et all. Similarly every argument you make for using C++ rather than Java et. all. there is a better argumant for using just plain C.

    No, @James, the problem is that, whatever argument is presented, some C-zealot will still yell "but code-bloat!" and "it's doing stuff behind my back!" while covering his eyes and plugging his ears. _And that's just the rational ones._ The others do as Torvalds does, say things like _"you are full of bullshit"_ instead of making any points, and honestly believe that this is any argument other than for them being infantile.

    @James: And unless you manage to explain why there is no room between portable assembler (you do know that C was created as such, don't you?) and half-interpreted languages on virtual machines, I will have to decide which of those categories to put your "argument".

    "That's mostly an attitude problem": I do not think C is used more often in OSS than in the industry, and even if that were the case, I do not think it would be an "attitude problem" due to prejudice. -1

    Well, C++ *is* doing lots of stuff behind your back. Whether or not it is good or bad, that's another question. But fact is that it is much more difficult to understand what kind of code a typical C++ program is going to be translated to than a typical C program. There is a complexity there which burdens a C++ programmer more than it does a C programmer.

    @JesperE As it happens, I have changed jobs since I wrote that, and I am now programming for embedded devices. We're using C++, and it's remarkable what the STL and template meta-programming can do for you when you have weak hardware and hard realtime constraints as well as reliability necessities. (We're doing power plants.) Yes, you have to know whether you should use a `std::vector` or an `std::map` for a certain piece of code — but you do not have to implement it yourself, but can rely on well-tested, highly performant, and dependable library implementations offering high abstractions.

    The problem with high-level abstractions in C++ is that many of the abstractions are **leaky** (, which means that you often need to understand the underlying implementation anyway. My favorite example of this is the "static initialization order fiasco": C++ certainly has some good features, but they also offer you many new chances to shoot yourself in the foot.

    @JesperE In my whole C++ experience, I've never had to read implementation of standard library I was using. And yes, I wrote embedded stuff too. Neither I had or wanted to look at assembly code; if I wanted to use assembly, I'd write in assembly, but any other language (C is *not* an exception here) was made to provide, uh-oh, abstraction over it and machine code. Now, do you understand implementation of C standard library you are using?

    @BartekBanachewicz yes, I've had to step through STL/Boost code as well as C standard library functions all too often to figure out weird crashes. I cannot claim to understand all of the C standard library, but the C standard library is **definitely** easier to grasp than the C++ one.

    Easier to grasp? But of course, these two are hardly comparable in terms of functionality, so it's rather obvious that C++'s std implementation is more complicated. Notice however how at the same time C++ containers prove to be much simpler and less error prone to use. That's the point of the library after all, don't you think?

    @JesperE: IMO the only time the STL abstractions are leaky is at compile-time, e.g. when you pass `std::list` iterators into `std::sort`, and all hell breaks lose. Otherwise it's a damn well-created abstraction. And if you feel you need to step through std lib code, you're likely doing something wrong. I cannot remember having needed to step through either `std::printf` or `operator<<` for built-ins. I have indeed looked at their code, though, to satisfy my curiosity, and I certainly think they are both mostly unreadable.

    There are so many, many, places in C++ where the abstractions are leaky (i.e. where you need to know the underlying details in order not to step on any mines), but many C++-programmers are so home-blind that they just see it as the way things work. I really suggest that you read Joel Spolskys artikle on leaky abstractions. It will make you a better C++-programmer.

    @JesperE: I guess I first read that article a decade ago. And you might have a point about programmers being home-blind about their beloved language — but this applies to C programmers just as well, so it's not an argument pro or contra either side.

    But C programmers typically do not boast about the superior abstractions of C, rather the opposite. I think Damien Katz makes a good point of C being "honest about its tradeoffs".

    @JesperE: Indeed, C programmers instead boast about how C++ is so bloated and how it does things behind your back. Full circle. HAND.

    You seem to be treating this as a boxing match, where we have to determine who of C and C++ is going to win. Fact is that both C and C++ is out there, and not acknowledging the problems in the tools you work with is not going to make you a better programmer. Yes, C programmers bitch about C++ and vice versa, but trying to select a winner is meaningless.

    These comments would have you believe that C++ compilers are essentially 'perfect'. The reality is, that C++ has runtime requirements that are hidden from the developer, and any ASM dump will confirm this - even with simple container class templates, iterators, move semantics, lambdas, etc. For example: 8-bit AVR gcc generates compact code, whereas a C++ runtime will probably break the EEPROM budget.

    @user103164 There are three sources of that I know of. Code to run constructors/destructors at static init/deinit which is tiny and you can avoid, and exceptions and runtime type information both of which gcc and most other compilers will let you toggle off.

    It's sad that no answer mentions legacy software. Personally, I use C only to maintain legacy software. For an existing application with 20 data processing programs written in C, I'll still choose to develop a new one in C just to keep it coherent.

    @EtsitpabNioliv: While people do that, it's not a very good reason. C++ was made compatible with C deliberately (and at great cost, given C's abysmal syntax). You not taking advantage of that by writing new code in C++ is just bad.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM