C (programming language) is a former featured article. Please see the links under Article milestones below for its original nomination page (for older articles, check the nomination archive) and why it was removed.
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science
This article is within the scope of WikiProject C/C++, a collaborative effort to improve the coverage of C and C++ topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.C/C++Wikipedia:WikiProject C/C++Template:WikiProject C/C++C/C++
The high efficiency of C deserves more of a mention in the article, despite the efforts of a certain pair of Wikipedia editors who want to hide the fact that C is much more efficient than Python. However, since I am outnumbered, there does not seem to be anything that I can do about it. Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO (talk) 02:57, 29 August 2025 (UTC)[reply]
I won't speak for anyone else, but all I want is for the sourcing requirements to be followed. Come up with a proper source and I will have no further objections. MrOllie (talk) 02:58, 29 August 2025 (UTC)[reply]
I'm going to revert the inclusion, and here is why: what you have is a primary source, a research paper, that looks at the question of energy efficiency. You have cited the same paper three times, but it is a single WP:PRIMARY source. Please read that link. Wikipedia articles should be written from secondary sources, so that is the first problem. Nevertheless, if the paper unequivocally showed what you say it does, and if that were uncontroversial, we could let it go. But it is not. you quote the paper comparing C and Python. But of course C uses less energy and is more efficient than Python. You are comparing apples and oranges. But the claim you have made is that C generally uses less energy than other languages, which is not what the paper says. For instance, the fasta results table put Fortran and Rust ahead of C. So what you are doing is synthesising a conclusion based on the data in that primary source and your own editor selection of the parameters. Incidentally it goes without question that more efficient languages consume less energy. Whether it needs saying is unclear, but we could say that. Your attempts to quantize this, however, are not appropriate and especially from a primary source. Sirfurboy🏄 (talk) 08:24, 30 August 2025 (UTC)[reply]
"you quote the paper comparing C and Python"
No, I paraphrased the paper, and I cited the paper. However, I did not quote the paper. How would I quote a claim in a data table?
"Incidentally it goes without question that more efficient languages consume less energy."
It does not go without saying which languages are more efficient or by how much of a difference.
C won in the normalized global results between the various benchmarks. (table 4). C won in the global results between the Rosetta code benchmarks. (table 13) C won in various individual benchmarks, such as binary-tree, fannkuch-redux, MergeSort, Hailstone, Ackermann, 100-doors, and N-queens. C won in the DRAM energy consumption benchmark. In the benchmarks where C did not win in energy usage, it lost by a very narrow margin to other systems level languages.
"Your attempts to quantize this, however, are not appropriate"
You are wrong. You are flat out wrong, and you are acting in very bad faith. Are you friends with MrOllie? Is this why you have reverted my edit? You are spouting nonsense about my edit being "SYNTHesis" and "comparing apples and oranges", yet my edit was neither. Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO (talk) 14:45, 30 August 2025 (UTC)[reply]
No, I paraphrased
The distinction is not relevant here. Let's calm down here a bit.Can we agree at least to drop the first sentence of your proposed change? All you mentioned just may show C is more efficient than Python, not other languages in general. Aaron Liu (talk) 14:48, 30 August 2025 (UTC)[reply]
I suppose that I could drop the first sentence, and I suppose that I could move it to another section of the article.
"Neither is this the place in the article for it"
Where in the article should it go? I have already been told that the lead is not the section in the article for it.
"Can we agree at least to drop the first sentence of your proposed change?"
I'm not Sirfurboy, but I don't think "C is more efficient than Python" should be included that prominently along other intrinsic characteristics of the language either. It's such as obvious thing, because the most common implementation of Python is interpreted and developers have had way longer time to optimize (compiled) C implementations, and placing it there makes it seem far more important than it actually is—as important as curly-brace blocks, pointer syntax, and implicit conversion, for example.There's also what Sirfurboy mentioned: Characteristics of implementations are not necessarily characteristics of the language, Python could've well favored a compiled reference implementation from the start instead of an interpreted one; in fact, there is a compiled version of Python called Cython, and it would be ridiculous to compare GCC 1.0 and Cython 1.0 and say the latter was more efficient because of the language's design/characteristics. This is why Sirfurboy believes you've made an exceptional claim. Aaron Liu (talk) 15:14, 30 August 2025 (UTC)[reply]
I am aware of Cython. However, modern GCC typically beats modern Cython.
Language characteristics impact performance. Undefined behavior would not exist in modern C if it did not have significant performance benefits. Dynamic type systems are less efficient than static type systems. (I am not talking about strong vs weak). Fixed precision integers are more efficient than arbitrary precision integers. I could create a very long list of design characteristics that impact performance; however, I doubt that it would help me in this argument to do so, so I shall not waste our time by doing so.
"It's such as obvious thing"
"you've made an exceptional claim"
If it is obvious, then it cannot be an exceptional claim. Besides, I have many "unreliable" sources that support my argument, as well. My claim is not "exceptional" to say that the implementations of C are much more efficient than the implementations of Python. Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO (talk) 15:27, 30 August 2025 (UTC)[reply]
I'll correct myself: It's an obvious thing that the most popular implementations of C are a ton more efficient than that of Python. It's an exceptional claim that all of this gap is because of the languages themselves. You need to have sources that say by themselves that the C language's characteristics—not the reference implementation being compiled or whatever—make it more efficient than all the others. Aaron Liu (talk) 21:31, 30 August 2025 (UTC)[reply]
Ah, perhaps we shouldn't go on a quest for some source that fits a particular requirement. Perhaps we should come up with text that reflects the information in the relevant reliable sources. The paper is WP:PRIMARY, so for sure some rules apply. It's arguably relevant to a page on C. It's also peer-reviewed which per WP:SCHOLARSHIP note on Reliable scholarship makes it WP:RS. How can we reflect this relevant, reliable source's content within the article? Chumpiht 21:47, 21:54, 30 August 2025 (UTC)[reply]
Then, can we agree that implementations of C are much more efficient than implementations of Python?
For the end user, it does not matter why the performance difference exists as long as it exists. The impact on the decision on whether to write a program in C or Python is the same regardless of whether the difference is due to language features or implementation details.
Why are we talking about Python at all? That is your fixation. That paper is specifically a study looking at fully 27 programming languages. It is not a study of C against Python - that is your interpretation of their data. It is not found in their conclusions. What the paper concludes is that a faster language is usually but not always more energy efficient. It is not speaking to a specific comparison of Python and C, and we cannot use their numbers to say in wikivoice that python uses 75.88 times more electricity. Again, this is not encyclopaedic writing and it should not be in the article. I mean, come on, 75.88? Only two decimal places? Sirfurboy🏄 (talk) 22:31, 30 August 2025 (UTC)[reply]
"That paper is specifically a study looking at fully 27 programming languages. It is not a study of C against Python."
If you really want to include all of the information about all of the other 25 programming languages that lose to C, then we can do so. Personally, I do not think that there is space in the article to add a section about each and every language that C is better than. If readers want all of those details, then they can read the paper themselves. It is a very good paper, and perhaps it should be an external link.
"It is not found in their conclusions."
Look at table 4. You are wrong. Also, look at table 13.
"75.88? Only two decimal places?"
Data Table 4 had two decimal places.
"we cannot use their numbers to say in wikivoice that python uses 75.88 times more electricity"
Table 4 is results, not conclusions. What you are not getting here is that you have started with the conclusion that you want in the article (that C uses one 75.88th of the electricity of Python), and you are reading this primary source in such a way that it supports our tertiary encyclopaedic article in making the claim. Yes, that is a result line in table 4 of the paper. But that is not what the paper is about, and so prominently making this claim in our article is simply undue. What secondary sources are talking about C in terms of energy efficiency? What do they say?You hit the nail on the head when you say Personally, I do not think that there is space in the article to add a section about each and every language that C is better than. You are right. Or almost right. The article has lots of space, but what you can clearly see is that if we write up about all 26 other languages covered in that article, then this article would no longer be about C but would be what that paper is about - a comparison of 27 languages for energy efficiency. Wikipedia articles need to be focussed on their subject. The subject is C, not Python nor any other language. How would you write about C's energy efficiency (or just efficiency) without mentioning any other language by name at all? That is the droid edit you are looking for. Sirfurboy🏄 (talk) 08:07, 31 August 2025 (UTC)[reply]
Fine by me. Probably just add it to the section I mentioned, though. I don't see much that'd be wrong with Certain typically-written Python benchmarks to use 75.88 times more electricity on average than the corresponding C benchmarks, while taking an average of 71.9 times more time to complete than the C benchmarks. On average, the Python benchmarks had a peak RAM usage that was 2.39 times more than the C benchmarks.[refs] plus a mention of what implementations were used and maybe plus some of the other compiled languages. Don't make it too long, though. Aaron Liu (talk) 22:58, 30 August 2025 (UTC)[reply]
Apologies to @CycleSortSupreme (formerly known as Lxvg...), but I've deleted the section they created on Efficiency. This discussion has not yet reached consensus. A section (before Hello World, even) is in my opinion be WP:UNDUE.
Perhaps a few words like The machine code compiled from programmes written in the C language leads to execution that is hugely more efficient than running interpreted, byte-coded or JITed languages. A like-for-like study found C coded samples to be around 70 times more energy- and CPU efficient than those written in Python, and the C code used less than half the RAM.Chumpiht06:48, 31 August 2025 (UTC)[reply]
I think any form of words should omit Python or any other language by name. C is efficient for lots of reasons, like optimised compilers that create native machine code, static typing, efficient memory management although actually the garbage collection issue is a bit more nuanced than many suppose etc. However we can say all that without referring to any other language. An article on C just has to explain that one reason for writing in C is it creates efficient and fast code (which also makes it low energy). Sirfurboy🏄 (talk) 08:19, 31 August 2025 (UTC)[reply]
Unsure why Python, the currently most popular language,[1] should be omitted. I don't see an issue with comparisons, especially when they're reasonably sourced. But that said, mine is not a strong stance. What words should go in? And where? Chumpiht18:44, 31 August 2025 (UTC)[reply]
I suppose that explaining the reasons for which C implementations are more efficient is okay; however, I am not sure where to find sources for those claims that people will accept as "reliable".
I know that as a rule of thumb, unoptimizing compilers tend to be approximately 9 times faster unoptimizing interpreters; however, I have no "reliable" source for that claim.
I know that static typing, manual memory management, second class arrays, fixed width integers, undefined behavior, pointers and pointer arithmetic, and various other features contribute to C having a low overhead. However, I am not sure what "reliable" source to cite for those claims.
I put the word "reliable" in quotes because I disagree with Wikipedia as to what sources are reliable. Personally, I think that arXiv, Stack Overflow, and Stack Exchange are typically reliable; however, it seems that Wikipedia does not agree. CycleSortSupreme (talk) 04:45, 1 September 2025 (UTC)[reply]
Look in a textbook. Here's something I found right away, but there will be more and with more detail:
Despite being insecure by nature, C programs run fast. Very fast. In fact, most of the “high- performance” libraries used by Python are actually written in C, then lightly wrapped with a tiny bit of Python code. The software in higher-level languages that run “on top” of C provides the security, flexibility, and convenience that C lacks. This makes sense: complex systems are built in layers. (Toal et al., 2024:267)
Toal, R., Strieker, S. & Berardini, M. (2024) Programming Language Explorations Boca Raton, London & New York:CRC Press
Anyone can submit to arXiv; the paper does not have to pass review to be there. Reliable sources submitted to arXiv usually get published in a journal later, where it may be cited. Posting something on arXiv or StackExchange does not make it more reliable than the same author(s) posting it on a blog. Aaron Liu (talk) 18:55, 1 September 2025 (UTC)[reply]
Anyone can submit to arXiv; the paper does not have to pass review to be there
arXiv is significantly moderated, even if it does not count as peer review. You cannot post anything to arXiv.
Also, Stack Exchange is heavily moderated. Granted, most of the moderation on Stack Exchange is moderating the questions instead of the answers.
Posting something on arXiv or StackExchange does not make it more reliable than the same author(s) posting it on a blog.
Anyone can post almost anything to their blog. Anything that can legally be posted online can be posted to a blog.
Stack Exchange and arXiv are significantly moderated, even if it is not peer review. Comparing them to a blog is not accurate.
Your comparison would be like saying that the Wikipedia featured articles are unreliable because anyone can create an account and edit them without peer review. CycleSortSupreme (talk) 03:49, 2 September 2025 (UTC)[reply]
arXiv moderation only makes sure submissions are on-topic scientific papers. StackOverflow does not remove incorrect answers either. That aside, the idea of WP:UGC is that we do not use user-generated sources no matter their moderation due to the lack of editorial control and how fast things can have an impact despite later removal, and ultimately citing better sources is always the safe option. Aaron Liu (talk) 21:27, 3 September 2025 (UTC)[reply]
Also, no source is completely reliable. In fact, most of the time, sources are only reliable on certain topics, even if that is not how Wikipedia sees it.
Are peer-reviewed sources reliable? Most of the time, they are. However, check out the following link for a peer-reviewed article that contained blatant errors yet was published in a "reputable" journal.
In fact, most of the time, sources are only reliable on certain topics, even if that is not how Wikipedia sees it. In fact, that is how Wikipedia sees it, see WP:CONTEXTMATTERS. You will run into far fewer problems here if you thoroughly read WP:RS and WP:V before continuing to make statements about what is and is not a reliable source. - MrOllie (talk) 12:20, 2 September 2025 (UTC)[reply]
"developers have had way longer time to optimize (compiled) C implementations"
C is approximately 1.53 times older than Python. Python is 34 years old. C is 52 years old.
When a change is disputed, it is often better practice to get agreement on the change first before rushing back to put it in the article again, because the latter can unfortunately raise the temperature in the room and escalate into WP:edit war. Aaron Liu (talk) 14:45, 30 August 2025 (UTC)[reply]
While perhaps amusing, this article is currently rated as C class. Something which might have the potential to boost the article's readability and quality could be to attempt to rewrite at least som of the lists as prose. I haven't been active in the development of any article on a programming language, but I came here as an active Wikipedian who sometimes programs in C in what WP:HOLICs call their second life; I am a person who cares about aesthetics I like writing and copy editing prose on Wikipedia. After perhaps very quickly checking the archives and active discussions, I do not see any obvious efforts in this direction, nor do I see consensus against it. Thus, I hereby request input from other contributors in regards to their opinions on the matter. This is to honor the everyone's privilege to voice their opinion, as this article is ostensibly backed by several active long-term Wikipedians who I presume may have formed an opinion on this. BlockArranger (talk) 22:57, 13 October 2025 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I am requesting comments to move the opening bracket ('{') from a newline to the same line as the signature. My reasoning is to cite this:[1] This is cited in the page "Hello, World!" program which provides a Hello, world program in C cited from the K&R book. If approved I will apply this change to both the original "Hello, world" program and the more modern version.
I would not recommend a change. I have programmed in C for a very long time, and opening braces were always put at the same position as the closing braces. In all C (and C++ books later on) this is the way programs are represented. Don't change it because in one publication it is different. Take a look at "The C programming language" of K&R and you will see what I mean. — DandoriD (talk) 10:24, 21 October 2025 (UTC)[reply]
Please see WP:RFCBEFORE. Where is the deadlocked dispute that has made a full-blown thirty-day formal RfC necessary? Aside from that, a C compiler simply does not care. Like most ALGOL-derived programming languages, you can write it all on one line, or each token on a separate line; you can have any number of leading spaces, tabs, both or neither; and it makes not one scrap of a difference. The only time that is does matter to the compiler is when you use preprocessor directives like #include <stdio.h> which must be followed by a newline. In short, this is valid:
When you write your own C programs, you can lay it out however you like. If you are at a university, they may teach you one way; another university might teach a different way. Neither of them is wrong. The only time that it "matters" is when you work for a company that has house style rules and you're sharing code with a programming team. --Redrose64 🌹 (talk) 20:30, 21 October 2025 (UTC)[reply]
Like Dandorid, I would not recommend a change either. For the function body, I've almost always seen the opening and closing braces on their own lines in actual C sources. Since this style is very common, we should follow it (at least, for existing examples in WP, we should not change it to some other, rarely used style). The K&R book is very old, and practice has evolved to ease readability. — Vincent Lefèvre (talk) 23:41, 21 October 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
level-4 vital article is rated C-class on Wikipedia's content assessment scale.
