Wikipedia

Talk:C (programming language)

(Redirected from Talk:C programming language)
Latest comment: 1 day ago by Chumpih in topic Energy Usage
Learn more about this page
Former featured articleC (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.
Article milestones
DateProcessResult
March 15, 2004Featured article candidatePromoted
July 25, 2006Featured article reviewDemoted
September 9, 2006Good article nomineeNot listed
Current status: Former featured article

Duplicate sections on related languages - merge?

edit
Latest comment: 1 month ago2 comments2 people in discussion

There appears to be two similar sections in the main article: Relations to other languages and Related languages. Former is a list within the Overview section; latter is an exposition on the influence of C, sitting near the end of the article.

Should we consider these as duplicates, and merge them to one ___location? Or are we happy with the different emphasis on the somewhat similar content, and leave well alone? Or Perhaps replace the first section with a sentence and keep the latter section? Or something else? Chumpih t 05:29, 26 April 2024 (UTC)Reply

IMO duplicate info should almost always be eliminated. These sections should be merged. ... There is lots of duplicate info throughout the article that bloats the length without adding value. I think the article has become crufty since it has been edited a zillion times by a zillion people. Needs refactoring :) Stevebroshar (talk) 12:10, 11 July 2025 (UTC)Reply

C is a compiled language

edit
Latest comment: 1 month ago13 comments8 people in discussion

A compiled language is "typically" compiled according to Wikipedia. I would like to add "compiled" to describe C. In fact, C is one of the most common languages, if not the most common language, cited as an example of a compiled language. Chris.temp.level.0 (talk) 13:27, 17 July 2024 (UTC)Reply

@Vincent Lefèvre and Jkudlick: The issue seems to be this edit which inserted "compiled" before "general-purpose programming language" in the lead. Per WP:LEAD, information in the introduction should be a summary of what is in the body of the article and it looks as if one reason given for a revert was doubt about whether the information is in the body. Bear in mind that the lead already refers to "compile" in a couple of places: "C compilers" + "designed to be compiled" + "can be compiled". People like fiddling and Google tells us that C interpreters exist although of course if the term "compiled language" has any meaning, it certainly applies to C. Johnuniq (talk) 01:43, 18 July 2024 (UTC)Reply
@Johnuniq, Chris.temp.level.0, and Vincent Lefèvre: I was only involved insofar as this article has pending changes protection and I happened to review a pending change that had already been reverted. As I stated on my talk page, I would have accepted the edit if it had not already been reverted. I am glad to see Chris has engaged in discussion here to reach consensus, and I will leave the discussion to those with much better knowledge of this subject than me. — Jkudlick ⚓ (talk) 23:29, 18 July 2024 (UTC)Reply
@Jkudlick, Johnuniq, and Chris.temp.level.0: I think that "designed to be compiled" already present in the LEDE is sufficient. — Vincent Lefèvre (talk) 12:00, 20 July 2024 (UTC)Reply
Agree. Chumpih t 14:34, 20 July 2024 (UTC)Reply
Originally intended to be compiled, yes. Originally designed to be compiled, sure. But that was decades ago. Is it still designed to be compiled? IMO that's arguable. Stevebroshar (talk) 12:07, 11 July 2025 (UTC)Reply
I worked at a company that sold a product with a C interpreter. C is typically compiled yes. But it doesn't have to be. In fact, any language can be either compiled or interpreted. IOW, there is no such thing as a compiled language or interpreted language. There are languages and there are compilers and interpreters that accept input in some language. Stevebroshar (talk) 12:05, 11 July 2025 (UTC)Reply
No, some languages must not be compiled. This is the case of shell scripts, for which any syntax error must not yield an error as long as the corresponding line is not attempted to be executed. — Vincent Lefèvre (talk) 12:11, 11 July 2025 (UTC)Reply
Technically, it may be correct that any language can be "compiled" or interpreted. However, it is extremely misleading to claim that there is no distinction between compiled languages and interpreted languages. As Vincent Lefèvre pointed out, shell scripts should not yield an error as long as the corresponding line is not "attempted to be executed". The only feasible way to "compile" such a language would be to bundle an interpreter into a binary with the language. Some languages are clearly designed to be interpreted. Languages with a eval function like Javascript and Python would require an entire interpreter or JIT compiler to be bundled into the executable if such a function was called with a runtime value. Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO (talk) 03:06, 18 July 2025 (UTC)Reply
Note however that Perl is a compiled language with an eval function. The whole compilation step is done before execution of the script or of the eval'ed code. Contrary to purely interpreted languages, any syntax error is detected, even if the corresponding code would not be reached during execution.
EDIT: And in Perl, it is possible to call functions before their declaration/definition (this would not have been possible if Perl scripts were interpreted).
— Vincent Lefèvre (talk) 17:48, 19 July 2025 (UTC)Reply
Perl is not really compiled. Perl 6 (aka Raku) converts to Parrot bytecode, which is interpreted. Thus, Perl 6 (aka Raku) is bytecode interpreted, which is how Java and Python work, as well. Perl 5 supported an internal bytecode. Perl 4 and below generate a parse tree before interpreting. You can correct me if I am incorrect about perl; however, I do not think that I am.
Compilation is about code generation. If machine code is never generated, then the implementation is interpreted. If machine code is generated while the program is running, then the implementation is JIT compiled. If machine code is generated before the program is ran, then the implementation is AoT compiled.
Most interpreted languages can be implemented with a JIT compiler, for example, Javascript. However, AoT compilation and JIT compilation are very different. Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO (talk) 23:24, 19 July 2025 (UTC)Reply
Compilation is the process of converting a program from one representation to another - if source code is turned into bytecode, that is still compilation. MrOllie (talk) 00:05, 20 July 2025 (UTC)Reply
Yes, and even machine code of an actual processor is interpreted, either in hardware by the processor itself or in software by an emulator. — Vincent Lefèvre (talk) 14:04, 20 July 2025 (UTC)Reply

Remove {{harvtxt}} templates?

edit
Latest comment: 2 months ago18 comments3 people in discussion

The article has several {{harvtxt}} references within it, leading to shortened references that have to be clicked through to get to a second link to the reference within the Sources section, which can then be clicked to see the source. The shortened references use the {{cite Q}} template, which dereferences wikidata. It would appear that there are multiple wikidata entries in this article's Sources section that are pointing to the same source. More info is at harvtext template usage and Template:Cite_Q.
There are four of them, compared to the 60ish more common references in the References. An example is HERE
Any objections to these four {{harvtxt}} references being removed, (along with the Sources section) and replaced with standard Cites, alongside the 60ish other cites? Chumpih t 23:29, 12 June 2025 (UTC)Reply

No, I don't see a reason why that would be the ideal CITEVAR for this article. Remsense 🌈 论 23:32, 12 June 2025 (UTC)Reply
I have no objections at all, and would prefer to have either all long or all short (either is fine), but not the random mix there is now. I am currently trying to untangle the THREE sources to the 1993 Ritchie paper, but stepped away for the moment because {{cite Q}} is annoying me. I was also thinking the {{harvtxt}}s should be {{efn}}s, but hadn't started focusing on that yet. Elrondil (talk) 02:31, 13 June 2025 (UTC)Reply
While the Ritchie source it is a very, very good paper, I totally agree, three refs to it is a little over-the-top.😁
Ok, given this approbation, and unless someone objects in the next 24h or so, I'll remove the Sources section, and change the Ritchie refs etc. to {{cite}}s. Chumpih t 06:46, 13 June 2025 (UTC)Reply
Ah, @Elrondil, I note that some of the {{harvtxt}} links have been changed to {{efn}}s with {{sfnp}} references HERE and similar. Are we still OK to remove the Sources section, the {{Cite Q}}s, and move to more typical {{cite}}s? Chumpih t 06:19, 14 June 2025 (UTC)Reply
@Chumpih: Oops, I forgot one {{harvtxt}}, so just moved that to {{sfnp}}s ... just wanted to finish what I had started :-). I still "prefer to have either all long or all short (either is fine), but not the random mix there is now." So I'm OK for you to move the {{sfnp}}s to refs (or {{r}}s?!?!). But I think regressing the {{cite Q}}s to ordinary {{cite book}} etc. is a bad move, so don't agree with that ... {{cite Q}}s enable data normalization and all the benefits that come with that. However, I'm not sure Remsense agrees with dropping the {{sfnp}}s after reading their response from a few days ago again. Elrondil (talk) 06:35, 14 June 2025 (UTC)Reply
Yeah, I made a 'negative' request, saying 'any objections', which was unclear of me - apologies. So the reply above from @Remsense could do with clarification. Chumpih t 06:49, 14 June 2025 (UTC)Reply
Sorry 😀.
If only we, the writers, expressed citations in a way that permitted them, the readers, to elect how THEY want to SEE the blimmin' citations and then let Wikipedia render the citations into whatever format a particular reader has chosen to see them (i.e., long, short, mixed, whatever), there wouldn't be a need for all this consensus BS, where a small set of writers (usually the most recent and most aggressive mob) decides for EVERYONE how they should "eat their meal". Its ridiculous, uncivil, and technologically quite unnecessary. Elrondil (talk) 07:07, 14 June 2025 (UTC)Reply
OK, so do we settle on standard {{cite}} references for all, (i.e. change them into the same format as the other 60-odd) or do we want to have these 5 (or is it 2) references in the Sources section using different mechanisms, with limited hover-over info, and an additional click required to get to the source? Chumpih t 19:30, 15 June 2025 (UTC)Reply
@Chumpih: What do you mean by "standard {{cite}}"? If you mean replacing the short citations using {{sfnp}} with long citations using <ref></ref>{{rp}}s while retaining the {{cite Q}}s, you have my OK but this also needs a clear and unambiguous OK from Remsense for there to be the required consensus. I see no reason to revert from {{cite Q}}s to {{cite book}}s etc.
Elrondil (talk) 19:46, 15 June 2025 (UTC)Reply
FYI, in my browser, hovering over a short citation opens a flyover with short citation details, and when I hover on THAT it opens a flyover with the long citation details … so I click just once. Elrondil (talk) 05:51, 16 June 2025 (UTC)Reply
That's not as straightforward as {{cite}}. Chumpih t 17:51, 16 June 2025 (UTC)Reply
True, there is an extra "level of indirection", but which enables (1) moving of the page or ___location from being inline to that extra level of indirection and (2) more control over how the long citations are organised. I see the benefits and costs of both approaches, and personally I think that should be the reader's choice (through a configuration setting), but instead Wikipedia editors have spend decades fighting over this, and will continue to … until each individual reader gets to choose how they feel at any moment: light mode or dark mode, sans serif or serif font, large text or small text, long citations or short citations, DMY or MDY dates, American or British or Australian or Hibernian or Indian English, metric or imperial units first, and so on.
In the meantime, we can still try to be as consistent as possible for the sake of readability by Wikipedia readers (that is, not author-centric but reader-centric), and to link any short and long citations that ARE there to pick up and correct mismatches (there are plenty) and at least ENABLE that extra hover or click instead of leaving it to readers to manually having to make the connection. Instead we have this ridiculous Lilliputian but cleverly-named WP:CITEVAR (or "Cite War") stand off with both short and long at the same time in the same articles. Elrondil (talk) 22:25, 16 June 2025 (UTC)Reply
So do you object to removing the Sources section and changing the remaining handful of {{sfnp}} (formerly {{harvtxt}} ) cites to become {{cite}}s like the other 60 on the page? Chumpih t 06:02, 17 June 2025 (UTC)Reply
I do not object to you changing the {{sfnp}} short citations to <ref></ref>{{rp}} or {{r}} long citations.
I do object to you replacing {{cite Q}}s with {{cite book}} etc (if that is what you also wanted to do).
I do object to you doing this without unambiguous consensus with Remsense. Elrondil (talk) 06:15, 17 June 2025 (UTC)Reply
@Chumpih: However, if there does end up being consensus for regressing the normalizing {{cite Q}}s to de-normalized {{cite book}}s etc., that could easily be done by adding |expand=yes to the {{cite Q}}s and taking it from there. Elrondil (talk) 06:43, 14 June 2025 (UTC)Reply
But what are "standard Cites"? 😀 There is no such thing in Wikipedia and everyone does what they want anyway. Elrondil (talk) 02:58, 13 June 2025 (UTC)Reply
Ah, true, true! Chumpih t 06:39, 13 June 2025 (UTC)Reply

Holy c needs to be added as a dialect

edit
Latest comment: 29 days ago1 comment1 person in discussion

. Tankfarter (talk) 05:38, 28 July 2025 (UTC)Reply

Energy Usage

edit
Latest comment: 1 day ago9 comments6 people in discussion

This whole section is absolutely bizarre:

Originally, C was popular mostly due to being easier to use than other programming languages.[citation needed] Currently, C is popular mostly due to speed, efficiency, low memory usage, and simplicity.[citation needed] C uses approximately one-eightieth the energy that Python, Perl, and PHP do.[17] On average, C uses less energy than Fortran, despite Fortran being faster on average.[citation needed]

But this line in particular:

C uses approximately one-eightieth the energy that Python, Perl, and PHP do.[17]

Is particularly problematic, as it gives the reader the understanding that C always uses 1/80 of the energy of the other listed languages, when in fact, it uses this while running these specific benchmarks, which have very little (if anything) to do with the real-world use of a language. Let's take Python for example. Which Python? Python 3.13? Python 2.6? CPython 3.13? Pypy 3.8? C as compiled with what? A "typical" C implementation of a given program probably does use substantially less energy than a "typical" Perl equivalent, but stating 1/80 based on some benchmarks makes no sense.

The entire section reads as something you would read on a website comparing Linux distros where it's clear the author has no idea what they're talking about. 196.211.140.249 (talk) 08:55, 21 August 2025 (UTC)Reply

That was added at 02:36, 18 July 2025 and should probably be removed. I doubt sites.google.com is a reliable source. Also, the WP:LEAD is supposed to be a summary of what is in the article. The lead should not be used to add ideas. Johnuniq (talk) 09:13, 21 August 2025 (UTC)Reply
Lets not pretend that C uses the same energy usage as Python. The Cython website claims benchmarks where Cython beat the reference implementation of Python in speed by a factor of 95. Even Cython, which few Python users use, uses more energy than typical C program equivalents. Almost all Python users use the reference implementation, which is well known for wasting CPU time, RAM, electricity, etc. Obviously, 95 is higher than the 80 times energy usage increase stated; however, the difference between 95 and 80 can be attributed to the fact that speed is not the same as energy usage.
Somewhere else on the internet, I saw something where someone got a 75 times speedup in the training of a neural network by rewriting their Python to C, while using the same machine learning library. However, I do not remember where I saw that. Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO (talk) 20:07, 24 August 2025 (UTC)Reply
The point, which has not been acknowledged, is we don't cite user-generated sources in any instance. Remsense 🌈 论 20:11, 24 August 2025 (UTC)Reply
This was returned with a WP:ARXIV preprint, which is another kind of user-generated source, so that's not any better. Kindly secure agreement on this talk page before reinserting any variation of this claim. MrOllie (talk) 21:29, 24 August 2025 (UTC)Reply
@MrOllie, I looked via Google Scholar and thought I saw another version of the paper published somewhere on Harvard's webspace, but I clicked in and saw it was just another arXiv portal or something, whoops. Sorry for the confusion. Remsense 🌈 论 01:05, 25 August 2025 (UTC)Reply
In many implementations, C compiles directly to machine code that runs directly on the target procsssor. Many other languages are either JITting, or use bytecodes which are considerably less efficient. While C is far from unique in producing machine code, it is totemic in doing so, and engineers choose C for its close-to-machine output. Perhaps words should go in the lede (or elsewhere) to extol this close-to-machine benefit of the language, perhaps alongside comparisons to other compiled languages. I don't think citing 80x or similar is wise, given how context-dependent such figures will be. Chumpih t 22:48, 24 August 2025 (UTC)Reply
That's more or less what the third paragraph of the lead is doing. MrOllie (talk) 01:10, 25 August 2025 (UTC)Reply
Yes, sort of. The 'designed to be compiled' part in lede para 3 is fine, but perhaps we should have words that spell out what that implies in terms of efficiency. This would be alongside other compiled languages, and in contrast to other languages which rely on interpreters, JIT, bytecodes, etc. Chumpih t 05:21, 25 August 2025 (UTC)Reply
Add topic
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:C_(programming_language)&oldid=1307695111"