Jump to content

Talk:C (programming language)/Archive 7

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 5Archive 6Archive 7Archive 8Archive 9Archive 10

Citations

I'm all for citing sources when appropriate, but I don't see the need to cite a source to support a claim like "the [C] language has therefore become available on a very wide range of platforms." By any reasonable definition, that is simply true. I also fail to see how it is POV, as Hdante claims in the revision history. Finally, if you insist on citing sources for border-line situations like these, I think you ought to just go ahead and cite the sources you think would be appropriate, not just lazily scatter {{fact}} tags throughout the article. {{fact}} is fine when the claim is begging for a citation, but it just clutters up the article in this case, IMHO. --Neilc 22:54, 30 July 2006 (UTC)

I agree with both Wrp103 and Neilc: system developers and implementors know well that C is the common language most likely available for new hardware or a new processor architecture. There is no need to cite this assertion—though one would be welcome. Likewise, there is no need to support the fact that K&R is the most basic language subset: This is self evident, given C's undisputed history. As for the "ardousness" of the C89 standardization, this is more worthy of a citation (and probably easier to find) than the others but, come on, it was a six year effort with plenty of cooks in the kitchen.... —EncMstr 23:31, 30 July 2006 (UTC)

The relevant sentences are:
  • Because of simplicity, the language has therefore become available on a very wide range of platforms - I don't agree that simplicity is the point here. I think it has became available on a range of platforms because its source was available and there was sharing among universities. Since the factual acuracy of the sentence can become dubious just by using a point of view, then it's obvious that the sentence itself has a point of view and needs a citation.
  • K&R C was often considered the most basic part of the language that a C compiler must support - how often ? who often considered that ? this sentence doesn't mean anything because of the weasel words. It could only make sense with a citation
  • After a long and arduous process - It was not arduous. It was a really simple and happy process.
  • C compilers exist for nearly all processors and operating systems - WP:WEASEL, WP:PEACOCK
  • and most C compilers output is well optimized - blablabla
Concerning scattering facts throughout the article: nothing cited is borderline, the facts were not inserted in random places, I don't have, by any means, to seek any information that I or anybody else would ever want and finally: with or without facts cluttering the text, the text either doesn't cite sources or doesn't agree to a neutral point of view. The absence of indication can't hide the low quality content of the article. Believe-me: it's better when an article says "I suck" than when it just sucks (why ?).
  • system developers and implementors know well that C is the common language most likely available for new hardware or a new processor architecture[citation needed] WP:WEASEL, WP:AXS
  • I agree that simplicity wasn't the main reason C was available on a number of platforms, although if it were hard to write a C compiler things might have been different. Originally it was because, if you could create a basic C compiler, you could have a complete OS for your new hardware, since Unix was pretty much totally written in C. Once gcc came along, it was extremely easy to create a C compiler for a new hardware platform, since gcc supported cross-compilations fairly easily.
  • In the early days, if you were a C compiler vendor but if you didn't support K&R C, then you need not bother trying to sell your product. That was the "bare necessities" of C compilers. K&R was the only official document for the C language, so each compiler had to support K&R at a minimum. Can anyone come up with an example of a C compiler that had any kind of market penetration, but didn't support K&R? Even after ANSI C came out, the compilers still had to support K&R because of the large code base already written in K&R. In fact, I have a routine available on my web site that is still written in K&R ... I've never bothered to convert it to ANSI because it works fine the way it is.
Supporting K&R C wasn't a big deal, C vendors were busy adding more and more features because of competition and a desire to improve on C (hint: performance). ANSI C incorporated a lot of those improvements (like assert). —Pelladon 07:46, 4 August 2006 (UTC)
Then your memories are distinctly different than mine. I recall once when we refused to buy a new model from one of our mainframe vendors because it didn't fully support K&R. A NULL pointer wasn't zero, but had some addressing info in the higher bits. As a result, if you used something like if (ptr), a NULL pointer would not return a false. We told them that was unacceptable. There was too much existing code that used that construct.
Any compiler that didn't support K&R was immediately disqualified for any purchasing decision. As for enhancements, when I wrote the coding standards for a project, I explicitly said not to use extensions, since that would lock them into that vendor. Performance was more a function of the hardware, not the compiler. Remember, back then there wasn't any common platform that everyone used. We didn't even have a single form of Unix, so we had to code for BSD/System V differences. If you depended on a particular compiler vendor, then you could only purchase the hardware that they supported, which removed one of the big arguments in favor of Unix. wrp103 (Bill Pringle) 13:06, 4 August 2006 (UTC)
I didn't realize that there were vendors that didn't support K&R, I'm surprised they did that (especially in the early days). —Pelladon 05:52, 9 August 2006 (UTC)
  • It took 6 years to develop the C standard, and a fair amount of negotiation had to take place to make sure everybody was happy with the result. So long doesn't seem to be much of a stretch, although I'm not convinced about arduous. Is there any citation about the process being simple and happy?
  • But C compilers do exist for most platforms and operating systems. If you were to make a list of the platforms/OS combinations that didn't support C, it would be very easy to come up with a much longer list of those that do.
  • C has long been recognized as being highly optimized, especially since gcc came along with excellent optimizations options. Since the C language is small and simple, compiler output, (even without any optimization) tended to be smaller and faster than most high level languages in the early days (you should have seen the original code generated by PL/I!). In fact, it is only recently that a case has been made that maybe C isn't as optimized as some think, as can be found in this SlashDot article, and that is mostly because of hardware features that are hard to take advantage of in C.
That is, compared to BASIC and LISP. All serious numerical processing was done in FORTRAN until the development of the standard c math library, and any Pascal compiler was more optimised than any C compiler. C optimisation didn't really start until they got the bugs out of their parsers, and even then it was limited by the separate-object compilation model and the lack of meta-data.—The preceding unsigned comment was added by 150.101.166.15 (talk • contribs) 08:13, 10 July 2007
On the original PDP-11 platform, the small process address space prevented implementing extensive analysis of (internal representations of) programs; besides, given the efficient mapping of C constructs onto PDP-11 instructions, the simple peephole instruction optimization and branch optimization resulted in very good code. Any "parser bugs" were unrelated to optimization. The main obstacle to optimization of C code is the possibility of "aliases" via pointers, which prevents a higher degree of caching in fast registers. C99 addressed that to some extent with restrict qualification, and the C standard also supports type-based nonaliasing assumption which helps. Many modern C compilers on many platforms do an excellent job of optimization. — DAGwyn 14:48, 10 July 2007 (UTC)
Where I teach (PSU Great Valley), we assume that all students taking IT classes know C. They may not be an expert, but the basic remedial programming classes are taught in C, and the assumption is that anyone who has been programming for any amount of time has run across C. (And if they haven't, they can pick it up fairly quickly.) Even though C isn't really meant for beginners, it is still taught for intro classes in many schools. I have a "Programming for Poets" type class that I put together that uses a combination of C and VB.
With the possible exception of some highly specialized embedded systems, I think you would have a hard time coming up with a decent sized list of platforms/systems that don't support C. If somebody can produce such a list, I would be interested in seeing it. wrp103 (Bill Pringle) 04:14, 31 July 2006 (UTC)

Without getting into details, I was involved in a similar fight for citations on Programming language. Basically, I feel that Wikipedia policy is that many things that you "know" are true (perhaps due to professional experience) still need to be cited. Remember the policy of "Verifiability, not truth". This article recently was removed as a Featured Article primarily for lack of citations, so it certainly needs more. I also do not agree that it is lazy to add {{fact}} tags without finding the citations yourself. In the past I have had success getting people to find citations once I explicitly listed where they were needed. --Ideogram 05:59, 31 July 2006 (UTC)


Concerning wrp103 response: it's obvious that you didn't understand what I've meant. I don't really agree or disagree with any "fact" I have written here in the talk page. Actually I agree with some things that I've tagged as needing citation, which means absolutely nothing to Wikipedia. Please, read again my arguments, having in mind that if such weak "facts" that I've written here were able to start a discussion, then the main article could not possibly be in a neutral point of view. --hdante 12:34, 31 July 2006 (UTC)


BTW (offtopic) There's no sense in talking that the C compiler is more or less optimizing. AFAICT, two-pass compilers just can't compete in optimization with multiple-pass (front end/back end) compilers. And multiple pass compilers use an intermediate representation to handle their data, so that it's independent of programming language. Early compilers were simple, not optimizing. Simplicity and optimization are not friends. I don't know what have you done in compiler optimization, but your talk seems to be outdated. --hdante 12:46, 31 July 2006 (UTC)
My experience is actually that C is extremely difficult to optimize. It's only been optimized as much as it has due to a great deal of focused research on procedural programs in particular, which is largely because of C's predominance. Early compilers certainly struggled to optimize even simple C programs due to complex issues of potential aliasing due to pointers, variables with long live ranges, and so on. I think if we're going to construct a discussion of why C programs are often more efficient than similar programs written in other languages, it should focus primarily on the level of detailed control given to the programmer, the efficiency of its primitive operations, the lack of overhead from a runtime infrastructure, and so on. Deco 20:54, 31 July 2006 (UTC)


Which is similar to what I was trying to say. Because the language was simple, the output tended to be more compact than more ambitious languages. For example, early PL/I compilers would translate something like if (a<b) x=y into 25-30 lines of machine instructions. I couldn't believe it the first time I looked at it, but because of all the various options within PL/I, and the fact that it wasn't too good at type checking, much of the code was spent determining the type of each variable, what option(s) were being used, as well as determining the correct operators. Compared to many other languages, C doesn't do that much "behind the scenes". The translation from source code to machine language is pretty straight forward.
Also remember that the things many people think about when discussing compiler optimizations these days weren't even dreamt about, let alone attempted, during the early days. Sometimes we were happy if the program worked correctly. I remember having a problem with a PL/I program shortly after the language was released. The solution was to rearrange the order of some functions. I was told: "Sometimes that fixes things!" ;^) wrp103 (Bill Pringle) 21:25, 31 July 2006 (UTC)
Hello ? If nobody has anything else to say, I'm reverting the article. --hdante 14:07, 1 August 2006 (UTC)
You might want to wait for an answer when you ask a question. wrp103 (Bill Pringle) 14:27, 1 August 2006 (UTC)

All this 'citations needed' stuff is ridiculous. The things demanding citations are not contentious at all. I have to think that the people demandinsg them are citation trolls. The whole thing makes wikipedia look like a big fat joke. - RichardAdams

Okay, I have addressed the "need citations" issue by rewording the statements in question into less controversial forms. In some cases, parts of the text was redundant with other statements elsewhere in the article, so I eliminated those redundancies. I don't think I lost any significant information, and I think the rewording is generally clearer. Since there are now plenty of references and no remaining flagged disputes about factual matters, I removed the "references" tag. If there are still disputes, feel free to add back some flags, but perhaps first you should discuss the specific issues. DAGwyn 23:23, 29 August 2006 (UTC)

Reasons for not promoting

Hi all,

I was very close to promoting this article to a good article. But I felt it was still in a state of transition and needed some further refining. My two main suggestions are:

  • Fix the citation tags.
  • Move the criticism section (4 screens worth) to a sub-page and summarize it in the main article.

Cedars 00:44, 7 August 2006 (UTC)

Since when has there been this disturbing trend to move only criticism off to a subpage? If anything, a discussion of pros and cons must take place -- not outright criticism. Dysprosia 00:49, 7 August 2006 (UTC)
Maybe it is my fault. I have done this for the Java criticisms section, because it has become very long and confusing for the reader and some of the critics could really be objected. I think we should have a normalized way to deal with pro and cons for computer languages. Some of them have no criticism sections at all : ADA, Basic, Fortran, C#, Python, Perl, Ruby (almost no critics). Some of them have several pages of them (this is the case for Java, and for C). The length of the criticism section does not say anything about what are the real cons for a language, so I think that to have a standard way to present pros and cons would be fair. Hervegirod 23:36, 7 August 2006 (UTC)
I agree with the idea that the criticisms section is unduly long compared to the rest of the article, and could be moved to a new (sub)article "Criticisms of C", with a summary mention of some of the main complaints. I think the citation policy is being carried to an unreasonable extreme here; except for the bit about optimization (which I think has rightly been removed), the flagged statements about C's ubiquity and significance are generally well established in the industry and known as such by personal experience of several independent contributing editors, who have as much credibility as any reference that could be cited, such as a survey in some trade magazine. (Such studies usually exhibit poor statistical methodology anyway.) If an article were to say that the Sun is very bright, would a citation be required? DAGwyn 10:24, 27 August 2006 (UTC)
I also think the "hello, world" example would be better as a separate, linked subarticle. DAGwyn 10:29, 27 August 2006 (UTC)
Speaking of the hello world example, the function prototype should be int main(int argc, char **argv). Is there a specific reason not to have this?Kreca 10:47, 27 August 2006 (UTC)
Both int main(void) and int main(int argc, char **argv) are equally valid definitions. If you are not going to use argc and argv, then why bother defining them?Mrjeff 09:24, 28 August 2006 (UTC)
That's right (there are these two distinct valid interfaces for main, according to the C standard), and even worse than that C99 allows the return to be omitted (for main only), automatically assuming return 0. I don't think it is useful to explore that in an introductory article. DAGwyn 20:49, 29 August 2006 (UTC)
Turns out that there is already a "hello world program" article, more general than just about the C example, so separating out the "hello, world" section would be problematic. DAGwyn 20:55, 30 August 2006 (UTC)
I moved the criticisms section to a separate article. It would benefit from some slight clean-up, in particular I didn't (yet) summarize the criticisms in the main page, just inserted a link to the new article. After that is done, the C article should be re-submitted as a "Good article". DAGwyn 21:58, 30 August 2006 (UTC)
I cleaned up the remaining "Criticism" section a bit more. It may be good enough to try resubmitting as a "Good article" now. I haven't yet done that, in order to provide some time for evaluation of the changes and discussion, if necessary. DAGwyn 04:07, 31 August 2006 (UTC)
Doing so is not in adherance with NPOV, unless you title the page differently, and include countering viewpoints. Any page including criticism must be balanced or Wikipedia takes a non-neutral view on a topic, which is not permitted. Dysprosia 04:26, 31 August 2006 (UTC)
That is a misunderstanding of WP:NPOV. C programming language, criticism does not criticise C, it describes existing criticism of C (and, from a glance, in a reasonably neutral manner, neither endorsing nor rejecting this criticism). Moving this to a seperate article is fine. I don't know if the name is perfect, but the concept is ok. It could use some sources, though. --Stephan Schulz 06:46, 31 August 2006 (UTC)
No. Presenting only criticism without response or other positive views is unbalanced and hence presents a one-sided view on a topic. That is not NPOV. Dysprosia 12:47, 31 August 2006 (UTC)
Note first of all that I did not create the C criticism text — it was already embedded within the main C programming language article, and I was merely responding to the requirement expressed at the start of this discussion topic that the criticism be moved to a separate page. Next, note that Stephan is correct in his observation that the criticism text is merely reporting on a factual matter, and is fairly well balanced, not just negative POV. Indeed, as one of the oldest proponents of C and a longstanding member of its standards committee, if I thought it had been too negative I would have added some counterbalancing comments to it. You can do so yourself if you think it necessary. What I am looking for feedback on is the act of moving that text to a separate article, not the (pre-existing) content of that text, which by the way now has its its own discussion page. DAGwyn 04:30, 1 September 2006 (UTC)
I'm not opposed to having the text. I'm opposed to it being the only thing in the criticism article (because, as I've outlined, doing so without balance isn't NPOV). There is no very strong reason that I can think of for having content based on analysis in another article. And as you suggest, I intend to look over the article for problems when I have some time. Dysprosia 02:06, 3 September 2006 (UTC)
Note the very first entry in this section, which seems like a pretty clear requirement to move the criticism section to a separate page. I think links are a useful tool for reducing clutter in main-line text. Also, the criticism section does have a fair amount of balance — and it really is undeniable that several of C's characteristics can be problematic for some people in some contexts, so the overall gist of such a section has to seem somewhat "negative". I did find a less-than-balanced piece of it a day or two ago and made it more neutral. Further contributions would be welcome, but let's try not to turn the criticisms article into a debate. — DAGwyn 05:55, 4 September 2006 (UTC)
I wasn't planning to. I haven't had a chance to have a close read of the article, but if the article is as balanced as you say, then there's no need to call the article a criticism of C, but more an analysis of the language with issues that people have found. Dysprosia 07:49, 4 September 2006 (UTC)
Criticism is not necessarily negative! --Stephan Schulz 08:28, 4 September 2006 (UTC)
This is true, but it's most common connotation is negative, and may be construed as such. That is undesirable. Dysprosia 12:05, 4 September 2006 (UTC)

Forth is lower than c

Forth is used quite a lot in bios or embedded devices where size is a issue. The new intel and amd64 are apparently written in plain c. Allix Fri Sep 1 13:59:01 BST 2006

So how is this supposed to bear on the C article? Also, your second sentence makes no sense. — DAGwyn 08:01, 2 September 2006 (UTC)

Requested move

C programming language → C (programming language) – Conformance with WP naming conventions LotLE×talk Note: Please notice the below info box. This is not a poll about C specifically, but about PLs in geeneral, many (but not all) of which use the pattern "FOO programming language" rather than the general WP disambiguation pattern "FOO (programming language)".

The following discussion is an archived debate of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the debate was move as outlined. -- tariqabjotu 02:43, 7 September 2006 (UTC)

Note: This poll has been transcluded onto the talk pages of a number of individual programming languages, but is in fact a subpage of Wikipedia talk:WikiProject Programming languages. When you comment, please note that this survey is for multiple programming languages, not just the one you saw it on.

Some editors have proposed a general rename of articles named with the pattern "FOO programming language" to the pattern "FOO (programming language)". Please note that this poll only is applicable to those programming languages whose names alone would introduce ambiguity. For example, programming languages such as Java and C , whose names alone are ambiguous, would be at Java (programming language) and C (programming language), respectively. Unique names such as Fortran and COBOL, should remain at their respective simple names.

For instructions on how to add a poll participation request to additional applicable article talk pages, please see: Wikipedia talk:WikiProject Programming languages#Poll procedure

Please add "* Support" or "* Oppose" followed by an optional brief explanation, then sign your opinion with ~~~~

Voting

  • Abstain Support - I initially abstained because I just wanted to get a procedure rolling. Looking at the first few comment, I support the rename. As with other editor, I only want this where ambiguity exists in the name: e.g. for "Python" but not for "Perl". Also, something like "Python programming language" would still redirect to "Python (programming language)" under the proposal, so existing links would not break. LotLE×talk 22:32, 1 September 2006 (UTC)
  • Support - However, I would object to specifying "programming language" anywhere in the title, as parenthetic remark or not, if the name of the language itself does not have any ambiguity issues. For example C programming language should change to C (programming language) (since C is already taken), but Fortran should stay at Fortran. --Serge 23:24, 1 September 2006 (UTC)
  • Support - originator of the request; it would also meet the common names policy and also meet the disambiguation guideline. atanamir 23:32, 1 September 2006 (UTC)
  • Oppose. The convention has been "<name of language> programming language" for quite a while and I don't think it helps by changing it now. There are already redirects in place for "<name> (programming language)" and it would only add more work to move them all there. Also, it goes against conventions in other media. In books related to programming on the copyright page where it sometimes has sorting information for the book many books say "Computers & Internet - <name> programming language I. Title" or something similar. - DNewhall 23:32, 1 September 2006 (UTC)
  • Oppose. To quote Wikipedia:Disambiguation, "When there is another word (such as Cheque instead of Check) or more complete name that is equally clear (such as Titan rocket), that should be used.". It is undeniable that the "C programming language" is a widely-understood name, not just a description. There's a reason K&R's book is called The C Programming Language rather than C, a Programming Language. Diverse examples from other areas include French language, Titan rocket, sticking plaster, bread roll, contract bridge. What makes programming languages different from these topics? Deco 23:44, 1 September 2006 (UTC)
    • If those articles were named like the programming languages are currently, they would have been something like sticking plaster dressing, bread roll food, and contract bridge card game. Titan rocket, in fact, is a redirect to Titan (rocket family). The natural languages are a slightly odd exception to the normal convention, but i'm not a linguist, and not about to argue with them. (I do know, however, that many non-English Wikipedias use the normal (parenthesized) disambiguation convention for natural languages.) --Piet Delport 13:40, 2 September 2006 (UTC)
      • Apologies for the bad example - Titan rocket was moved since it turned out to be a rocket family, but others such as Angara rocket were not. The controlling question here is whether "C programming language" is a "more complete name" for C. I argue that it is, and so standing guidelines strongly support the current name. Deco 10:12, 3 September 2006 (UTC)
        • I would argue that isn't. You can say "I play contract bridge" and "I use C", but not "I use C programming language". You can expand the names into noun phrases, as in "I play the contract bridge card game" and "I use the C programming language", but in both cases "the * card game" and "the * programming language" are not part of the name itself, anymore. --Piet Delport 06:04, 4 September 2006 (UTC)
          • The presence or absence of a leading article is not a reliable indicator of whether it's a name or not, as indicated by French language, unless you wish to expand this proposal to move X language -> X (language) as well. Deco 06:28, 4 September 2006 (UTC)
            • Definitely not something i'm interested in pursuing; let the linguists and editors involved with natural languages worry about their own naming convention. --Piet Delport 12:09, 4 September 2006 (UTC)
              • (I know I am commenting on a now old post, but...) My take on "French language" is that it's different from "C programming language" since French is the language of the French. However, "C" is not a language named after a culture, country, or people (or anything). "C" only refers to C; "French" refers to a whole lot more than a language. Also, "French" is descriptive, but "C" is not. There's no need to clarify "C" or let it modify a noun. But being that a one letter name for something is inherently ambiguous, as well as names such as "Java" or "Python" (as already mentioned), there needs to be the parenthetical, "(programming language)".
  • Support - due to its name being "Ruby". --Yath 01:31, 2 September 2006 (UTC)
  • Support - this is the standard way that most Wikipedia articles are named. Use the common name and disambiguate appropriately using parentheses when necessary. --Polaron | Talk 01:43, 2 September 2006 (UTC)
  • Oppose - For the same reasons as DNewhall. Chris Burrows 02:11, 2 September 2006 (UTC)
  • Oppose — Per Deco, I don't see how adding parentheses to an article title which is already clear is an improvement. --Craig Stuntz 02:47, 2 September 2006 (UTC)
  • Support -- Crypotography has had much the same problem for some time. It has adopted the "<topic> (cryptography)" approach which has worked well. Not elegant perhaps, but ... ww 05:20, 2 September 2006 (UTC)
  • Oppose — Either way, there should be a second link so that both "C (programming language)" and "C programming langage" produce the C article. My main reason for opposing is that it isn't really consistent with the new "C programming language, criticism" page that was spun off the main C article; what would that name turn into? By the way, the official standard name is "programming language C", but to me that sounds too much like "PL/C" which would be wrong. Deco's remark is quite right. — DAGwyn 07:56, 2 September 2006 (UTC)
  • Comment. This proposal is different from the original proposal, found here, which is now understood as having unanimous consensus in favour. Please do not interfere with the original proposition by misrepresenting it and opening a straw poll here, which can only serve to undermine the usefulness of the original proposal. It would have been much better to simply post a link. - Samsara (talk • contribs) 09:40, 2 September 2006 (UTC)
The original proposal seems pretty wacko to me, and I don't see any evidence of a consensus. As I understand it, this current section is not a "straw poll", but a genuine attempt to determine whether or not to move the C article to a new name, independently of whether that wacko proposal is accepted. — DAGwyn 09:53, 2 September 2006 (UTC)
In what way is "C programming language" misleading? I can't think of a more natural title for such an article. — DAGwyn 05:48, 4 September 2006 (UTC)

Discussion

Response to DNewhall's comment

In order to reduce clutter in the voting section, i've deicded to respond to DNewhall's vote here. If you're afraid of the amount of work it would take to move the articles, I can move most of them and i'm sure there are other editors willing to take up the task. Also, most books about programming languages simply have the title or common name of the programming language as the title of the book -- the Wrox series uses "Professional PHP" or "professional Java", not "professional PHP programming language" or "professional Java programming langauge". Many of the books I have also have the sorting information as "Computers -- Programming languages -- X," where X is the programming language. atanamir 23:36, 1 September 2006 (UTC)

The main issue is not that I'm afraid of the work but that it'll be a lot of work with next to no perceived benefit. Both "Euphoria programming language" and "Euphoria (programming language)" go to the same page and I (and others apparently) fail to see how that is an improvement over the current convention. The text is exactly the same, you're just adding parentheses. No one is going to get confused about the lack of parentheses (also remember that the names with parentheses already have redirects in place). Is "<name> (programming language)" a more correct title for the article? Arguably. Is it worth the effort of moving all the pages over from their perfectly understandable title to a title that already has a redirect in place for it? No. - DNewhall 16:10, 2 September 2006 (UTC)
I think you misunderstand the point of stylistic consistency on Wikipedia. Any one article in isolation would be fine under either convention; in fact, if the project was only the one article on, e.g. "C programming language" there would be no contrast with all the other uses of parens for disambiguation. But if WP (or some subset) was prepared for print or other syndication, having relatively consistent stylistic choices helps a lot (article naming is, of course, just one small issue among many others, of course). The work involved in a rename would, obviously, be a tiny fraction of the work involved in discussing the question, so that is "vanishingly insignificant". LotLE×talk 16:42, 2 September 2006 (UTC)
When it comes to C, we need to clear and distinct names for the articles on the programming language article and for the book. C (programming language) and The C Programming Language (book) are those two names. They are unambiguous and (or is that because?) they conform with the Wikipedia standard. Anything else should be a redirect to one or disambig page to both. 'C programming language' should redirect to the language and 'C Programming Language' to the book or a disambig page. The existence of a book called 'The C Programming Language' is actually an argument in Support. Aaron McDaid (talk - contribs) 12:49, 4 September 2006 (UTC)
... Appending to own comment ... It's never referred to directly as 'C programming language'. It's always 'C' or 'the C programming language. Note the ' the '. The latter is of the form 'the X Y' where X is the name and Y is the type of object. 'the X Y' (or even 'X Y') is not a new name for the object, simply a way to refer to X where there may be some ambiguity. Aaron McDaid (talk - contribs) 13:07, 4 September 2006 (UTC)

Repsonse to Deco's comment

Imagine if you have a set of objects which all fall under the same category -- let's say they're all different types of Widgets. The types are Alboo, Kabloo, Hello, Wawoob, Baboon, Choogoo, Chimpanzee, etc. Because some will cause ambiguity -- Hello, Baboon, and Chimpanzee -- they need to be disambiguated. However, since the common name (in this case, the real name) is "Hello," "Baboon," and "Chimpanzee," wikipedia has an established precedent of using parentheses. Thus, the unique widgets, Alboo, Kabloo, Wawoob, Coogoo, can have articles simply at the name itself; but the ambiguous names should have articles at Hello (widget), Baboon (widget), and Chimpanzee (widget). Thus, the article titles will be uniform in that they are all "at" the name itself, but with a disambiguator on several of them. This is easier than making all of the articles at Alboo widget, Kabloo widget, Hello widget, etc. Also, it allows for the pipe trick, so links can easily be made with [[Hello (widget)|]] --> Hello. atanamir 23:54, 1 September 2006 (UTC)

  • an example of this that's currently on wikipedia is colours. Some colours, such as Blue, Brown, and Red are at their articles, but colours like Orange (color) need the disambiguation part on them. It isn't at Orange color, althouh there is a redirect -- we can do the same thing with redirects. atanamir 23:57, 1 September 2006 (UTC)
  • Titan rocket may now be a redirect, since it turned out to be a family of rockets rather than a single rocket, but there are still many rockets named that way (e.g. Angara rocket) and it's still cited on Wikipedia:Disambiguation specifically. The miniscule convenience of the pipe trick is not a reason for anything. My point is that this is a much wider concern than programming languages alone and represents a significant departure from the disambiguation guidelines. It would be radical to make such changes in a single area without raising them to the wider community, when your argument seems to apply to everything. The point of contract bridge and bread roll is that the more common names for these topics are "bridge" and "roll". Deco 07:48, 2 September 2006 (UTC)

Simpler disambiguation

Even if we add the parentheses, the guideline at Wikipedia:Disambiguation#Specific topic makes sense to me:

If there is a choice between disambiguating with a generic class or with a context, choose whichever is simpler. Use the same disambiguating phrase for other topics within the same context.

For example, "(mythology)" rather than "(mythological figure)".

In this case, we could have the simpler and more widely applicable "(computing)" instead of the long "(programming language)". --TuukkaH 10:04, 2 September 2006 (UTC)

I agree with the sentiment, but i think "(computing)" is too wide, with way too much opportunity for clashes:
"(programming language)" might lean towards the long side, but i don't think any alternative class comes close to being as simultaneously large, well-defined and well-populated. --Piet Delport 15:14, 2 September 2006 (UTC)
I agree that if we were to use parentheses, "(computing)" is not specific enough. Your examples are excellent, particularly "Icon", which clashes with an already-existing article! Deco 10:40, 3 September 2006 (UTC)
Perhaps you're right in that it's not specific enough. On the other hand, the disambiguation can never be perfect as there are several programming languages that share a name: NPL has three programming languages, The Language List has four programming languages called G. What about "(language)" then? --TuukkaH 22:02, 3 September 2006 (UTC)
"Language" connotes something rather different from "programming language". "Lisp (language)" for example. "Programming language" is the accepted category in the industry, abbreviated to "PL" quite often in discussions (whereas "L" is never used for this). — DAGwyn 05:59, 4 September 2006 (UTC)
What about just "(programming)"? Or is that too ambiuguous as well? atanamir 02:39, 5 September 2006 (UTC)
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Pages like C programming language, criticism

To meet the new standard, the pages should be moved to something like Criticism of C (programming language), right? examples are Georgia (U.S. State) and Politics of Georgia (U.S. state). atanamir 02:42, 5 September 2006 (UTC)

Depends on the page in question, most likely; some would work like above, some (like C syntax) wouldn't require any changes, and some might want to use a different method to disambiguate. --Piet Delport 05:55, 5 September 2006 (UTC)
Agreed with Piet; only the ones that would incite ambiguity -- simply "Criticism of C" would have ambiguity, but "C syntax" or "Syntax of C" are both rather unambiguous and would not need change. atanamir 06:01, 5 September 2006 (UTC)
Surely, criticism of C is pretty unique and should be the article? Are there any other C's that would be criticized? Aaron McDaid (talk - contribs) 21:41, 5 September 2006 (UTC)
I agree that the most likely "C" to be criticised is the programming language, but some may be looking for a criticism of the letter or magazine. Unlikely, but possible. This decision would be left up to the community, though. atanamir 01:57, 6 September 2006 (UTC)
As of now, there is only one C that is criticized on Wikipedia, and I am not aware of anyone wanting to write an article criticizing any other Cs. Therefore, criticism of C is unique. The Wikipedia standard is to only disambiguate when necessary. That article should be moved to criticism of C at some point, but we should let this debate finish first. Aaron McDaid (talk - contribs) 09:16, 6 September 2006 (UTC)
For the record, "Criticism of C" didn't even exist until I created the redirect yesterday. Was kind of surprised because it was at that wierd, longish name and is a pretty good article :). RN 10:19, 6 September 2006 (UTC)
The C criticism article was split off from the main C article, where it had previously been embedded, in response to a requirement in order for the main C article to be designated a "Good Article". I picked the name with the idea that it was a sub-article of the main one. Once the discussion has settled, I don't object to some reasonable renaming, so long as the links between the two articles are fixed up so they still point to each other. — DAGwyn 21:51, 6 September 2006 (UTC)
Aaargh! Whoever just renamed the main C article ignored this linking issue. I have edited the C criticism article so its link to the C article does not have to redirect. — DAGwyn 20:20, 7 September 2006 (UTC)
The term "criticism" should not be used (I've stated reasons for this on Talk:C (programming language); the more accurate term of "analysis" or something similar should be used. Dysprosia 03:54, 7 September 2006 (UTC)
You also received feedback to the effect that criticism doesn't have to be negative, that the article is fairly balanced, and that a list of limitations has to seem somewhat negative no matter how well-intentioned it may be. The C criticisms article is not at all a complete analysis of the language, just a description of the many characteristics of C that have drawn reasonable criticism. Since C is so popular and wide-spread, it is a target for a lot of sniping and second-guessing, and it is undeniable that that has happened, which is part of what the C criticism article specifically addresses. One of the useful functions of the C criticism page is to bring some balance to that criticism. — DAGwyn 20:20, 7 September 2006 (UTC)
I also responded to that comment by saying (and I'll repeat the comment here for the benefit of readers of this page) that the term "criticism" still has primarily a negative connotation and that because of this it is an undesirable term. The article in question has the potential to contain discussion on design points on the language and opinions on those who comment on these design points. That is an analysis of the design of the language, and has the potential to encompass views from all points on the spectrum on the matter. Dysprosia 07:43, 8 September 2006 (UTC)
I just want to chip in that i agree with DAGwyn that "criticism" does not carry negative any primarily negative connotations in this context. As the criticism article says:
"In literary and academic contexts, the term most frequently refers to literary criticism, art criticism, or other such fields, and to scholars' attempts to understand the aesthetic object in depth."
There are certain fields ("In politics, for instance [...]") where "criticism" connotes mainly negative criticism, but it should be reasonably clear that encyclopedias won't limit themselves to that. --Piet Delport 23:32, 10 September 2006 (UTC)
Technically, it shouldn't carry any as you suggest but most seem to think it is a dumping ground for it. I would recommend "Analysis" as that's what I'm doing for criticism page I watch. RN 23:43, 10 September 2006 (UTC)
"Analysis" usually implies something more formal, complete and reductionistic, though. Is that what the article is aiming for? --Piet Delport 00:00, 11 September 2006 (UTC)
It doesn't need to imply that. The article in question however should aim to examine as many viewpoints on as many language points as possible. Dysprosia 02:33, 11 September 2006 (UTC)
Unfortunately, the C (programming language) article itself does force the negative connotation on the reader by saying "Despite its popularity, C has been widely criticized. Such criticisms fall into two broad classes: desirable operations that are too hard to achieve using unadorned C, and undesirable operations that are too easy to accidentally achieve while using C. Putting this another way, the safe, effective use of C requires more programmer skill, experience, effort, and attention to detail than is required for some other programming languages." That whole paragraph implies that the article Criticism of the C programming language is negative (why else say "Despite its popularity" and then cite two negative classes?) Mickraus 17:14, 24 January 2007 (UTC)
I'll just wait for someone else to paint the bikeshed — Preceding unsigned comment added by 121.211.204.77 (talk) 12:52, 6 July 2015 (UTC)

Burroughs MCP use of ALGOL?

I thought MCP was written primarily in ESPOL, which was a proprietary SIL that somewhat resembled ALGOL. — DAGwyn 09:34, 2 September 2006 (UTC)

I checked the reference manuals, and ESPOL is closely enough related to ALGOL that there is no need to adjust the current statement in the article. — DAGwyn 21:43, 7 September 2006 (UTC)

Failed GA nomination

I failed this article due to the fact that there are only nine references for a 49 kilobyte article. Besides that, it's great! Some P. Erson 00:06, 9 September 2006 (UTC)

Hello, world example

I tried using two different compilers (VS and gcc) and neither compiled main() { printf("Hello world"); }. They both assumed that main was an int and both assumed a default return value of 0, however they didn't "auto-include" stdio.h, and therefore they both gave a printf() not defined error. Are you sure that it is correct? Did anyone try to compile it? --Swalot 00:25, 17 September 2006 (UTC)

If you would have read the article closely, you would have seen these sentences: The above program will compile correctly on most modern compilers that are not in compliance mode. However, it produces several warning messages when compiled with a compiler that conforms to the ANSI C standard, and won't compile at all if the compiler strictly conforms to the C99 standard.
The example following it is presumably what you want. Dysprosia 01:48, 17 September 2006 (UTC)
I did read it closely, and that's why I used the most recent versions of VS and GCC, without the ANSI flag. And it wasn't a warning, it was an error. --Swalot 02:26, 17 September 2006 (UTC)
gcc accepts it fine:
$ cat > test.c
main() { printf("blah\n"); }
$ gcc test.c
test.c: In function 'main':
test.c:1: warning: incompatible implicit declaration of built-in function 'printf'
$ ./a.out
blah
and that was from gcc 4.0.3. Not including header files doesn't mean that your program can't be linked. Dysprosia 02:38, 17 September 2006 (UTC)
ok, sorry then :( --Swalot 03:16, 17 September 2006 (UTC)
Don't be sorry, at least we've resolved the matter :) Dysprosia 05:19, 17 September 2006 (UTC)
Note that the first form of the program was meant to illustrate what C was typically like in pre-Standard days. Perhaps that should be made clearer. — DAGwyn 06:06, 18 September 2006 (UTC)

C

Sir Since default data type of pointer variable is int, then how can it store value more than 32667. your faithfully Neeraj Pandey

This page is for discussions about the Wikipedia article "C (programming language)". Questions about C programming should be posted to the net newsgroup comp.lang.c instead. However, the simple answer is that your statement is wrong: pointer variables have their own specific types, which are never type "int", and while many C implementations do allow pointer values to be converted to and from some integer type without loss of information, that type isn't necessarily plain "int". Also, on many platforms type int can represent values much larger than 32767. — DAGwyn 19:22, 29 September 2006 (UTC)
Anyway, pointers can store calues till 65535 on 16-bit compilers or 4294967295 on 32-bit compilers. On 16 bit compilers, writing this should work: int far *n = 0 ; --200.126.153.25 21:36, 17 August 2007 (UTC)

C++ superset of C

Unless my memory is going, the original implementation of C++ was a preprocessor that translated the language into C, and then it was compiled with a regular C compiler. That is why I said it was originally a superset of C. Of course, saying it is nearly a superset of C is correct regardless of the state of my memory. ;^) wrp103 (Bill Pringle) 21:31, 27 October 2006 (UTC)

It is true that early implementations of C++ (and its forerunner "C with classes") used a preprocessor. However, they completely parsed the source language, and interpreted some things differently from how C compilers interpret them, so that the generated C source text was often not just a simple "copy through" of the C++ program source text. For example, "extern int foo();" declared the function as definitely not accepting any arguments (what is now known as "extern int foo(void);" in Standard C), whereas in C the same syntax has always declared the function as having unknown argument types. Also, character constants 'x' have type char in C++ but type int in C. There are other differences, too; see Tribble's page for more detail. There is a "common subset" of C and C++ that some programmers try to remain within, so that their code works under compilers for either language. But it's smaller than "all of C". — DAGwyn 06:13, 31 October 2006 (UTC)
Some versions of C++ still output C, and then expect you to compile that using a C compiler. However, some Haskell compilers do the same, and I don't think anyone would claim that Haskell is a superset of C :) Mrjeff 10:23, 31 October 2006 (UTC)
C++ came about before ANSII C, so the compiler didn't complain about how many arguments were used. What you are describing might be how some C++ compilers work now, but it wasn't the way the first OO versions of C worked. wrp103 (Bill Pringle) 14:20, 31 October 2006 (UTC)
Well the first C++ compiler was Cfront. [1] describes how it worked. The "C with classes" compiler could be described as you say, but the first compiler for C++ did it's own checking. Mrjeff 16:54, 31 October 2006 (UTC)
Yes, Pringle is simply wrong. The relevant "compiler" is the C++-to-C translator, not the back-end C compiler; the Haskell example should illustrate the point that one can't infer any similarities between the two languages just from the preprocessing construction. Even "C with classes" did function parameter type checking (at least within a translation unit). The types were also enforced for external names via the "name mangling" that embedded that type information into the interface, so that a mismatch would be caught by the linker.

A small set (around 30) of reserved keywords

Technically correct, and true in it's original context (as a system language), but a bit misleading. Look for example at the "Hello World" example. Is that written in C? With C? or what? Which part of C is sprintf? And if it's not part of C, why is it the classic example? Which part of the 'characteristics' section tells you that standard C includes standard libraries? I don't have a solution, but there is a disconect between that typical definition of C, and the language as actually used: that definition is of only technical importance, and not related to the language being demonstrated, which has hundreds of key words, which you can redefine, but don't. 218.214.148.10 01:37, 6 November 2006 (UTC)

C is fairly cleanly partitioned into: preprocessor, language, and library. This should probably be made clearer at the start of the "characteristics" list. DAGwyn 20:56, 7 November 2006 (UTC)
218.214.148.10, the use of library functions was well-known by the 1970's, where a library call was understood not to be part of the language, but a call to a facility provided by the operating environment, which tremendously simplifies the programming, and allowed a clean separation between implementation and language design. Some examples of this point of view can be found in languages like Jovial, which had no I/O. Thus Hello, world was an advance, because you could write a program without also writing the I/O library. See Free On-line Dictionary of Computing for more of this type of CS history. --Ancheta Wis 04:16, 14 December 2006 (UTC)
So sprintf is understood to be a call to the operating environment? That may have been true for a VAX, but it's not a helpful statement about C in general. (david) 150.101.166.15 02:27, 20 June 2007 (UTC)
Actually, sprintf is a call to the run-time environment, not the O/S. Section 2 were generally O/S calls, while section 3 functions were to the runtime. -- wrp103 (Bill Pringle) (Talk) 04:51, 20 June 2007 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:C_(programming_language)/Archive_7&oldid=1136586775"