Talk:C (programming language)/Archive 2

From Wikipedia, the free encyclopedia

 This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
← Archive 1 Archive 2 Archive 3 →

Contents

proposed new Overview

I'd like to replace the first two paragraphs of the Overview section with these three new ones:

C is a relatively minimalist programming language. Among its design goals were that it be efficiently compilable, that is, that machine language instructions corresponding to its core language elements can be straightforwardly generated, without extensive run-time support. It is quite possible to write C code at a low level of detail analogous to assembly language; in fact C is sometimes referred to (and not necessarily pejoratively) as a "high-level assembler" or "portable assembler".
In part due to its relatively low level and unpresumptuous feature set, C compilers can be developed comparatively easily. The language has therefore become available on a very wide range of platforms (probably more than for any other programming language in existence), and well-written C programs can therefore enjoy very wide portability.
C was originally developed (along with the Unix operating system with which it has long been associated) by programmers and for programmers. Nevertheless, it has enjoyed very widespread popularity, finding use in contexts well beyond its initial systems-programming roots.

Any comments or objections? Steve Summit (talk) 08:55, 30 December 2005 (UTC)

Looks good. Some tweaks for grammar etc.:
C is a relatively minimalistic programming language. Among its design goals was that it be efficiently compilable — that is, that machine language instructions corresponding to its core language elements could be straightforwardly generated, without extensive run-time support. It is quite possible to write C code at a low level of abstraction analogous to assembly language; in fact C is sometimes referred to (and not always pejoratively) as "high-level assembler" or "portable assembler".
In part due to its relatively low level and unpresumptuous feature set, C compilers can be developed comparatively easily. The language has therefore become available on a very wide range of platforms (probably more than any other programming language in existence), and well-written C programs can therefore enjoy very wide portability.
C was originally developed (along with the Unix operating system with which it has long been associated) by programmers and for programmers. Nevertheless, it has enjoyed very widespread popularity, finding use in contexts far beyond its initial systems-programming roots.
Also--what other language might possible be more widely implemented? And...in the last paragraph you say essentially "Originally, C was made for programmers; nevertheless, it has become popular and widely used [among programmers]." This sets up a contrast that fails to manifest. The language's history does involve a striking contrast--a language made for the use of a few Bell Labs employees, then used virtually unchanged by uncounted thousands of programmers for decades afterward. But this is not conveyed in the paragraph, and I can easily imagine readers being confused. I would lose "originally" and replace "nevertheless" with something like "subseqently" or "since then". DanielCristofani 10:13, 30 December 2005 (UTC)
Yes, your "striking contrast" is closer to what I was trying to convey. The third paragraph is arguably out of place in this overview, though, perhaps belonging under History. Basically what I was getting at is along the lines of what's already in the Introduction: "It is also commonly used in computer science education, despite not being designed for novices".
In terms of "what other language?", I certainly don't know of one, but I also don't know of a definitive source to cite to back up the availability claim, thus the "probably". Steve Summit (talk) 21:15, 30 December 2005 (UTC)
It's not terrible, but this glosses over several things:
  • There's a two-way relationship between instruction sets and C - the popularity of C has driven hardware designers to continue to support its key features in ever more efficient ways and not to remove things that it depends on. At the time of its design the fit wasn't quite as universal.
  • C is in many ways suboptimal as a "portable assembly" - in the words of the (admittedly biased) designers of C--, referring to the use of C as a translator's target language, "You might generate C, if you can live without multiple results in registers, proper tail calls, computed gotos, accurate garbage collection, and efficient exceptions." [1]
  • One of my favourite sayings is: it's easy to write a C compiler, but it's extremely difficult to write a good optimizing C compiler. It's also nearly impossible to prove a C program fragment correct (in fact, one generally has to assume certain border cases won't occur). C is very difficult to analyze.
Agree on change of nevertheless. Would like to see unpresumptuous changed also. Deco 10:44, 30 December 2005 (UTC)
"Not terrible." You're too kind. :-) But since what's there now is terrible, I guess I won't pull out the seppuku knife just yet.
We could debate the three "glossed over" points you menton, but since this is an Overview I think it's appropriate to gloss over them in any case. (But to clarify: when I wrote "machine language instructions corresponding to its core language elements" I wasn't actually alluding to instruction set compatibility at all, but rather the goal that C's types and operators be chosen such that each operator could typically compile to a single instruction or a handful of instructions, as opposed to elaborate run-time subroutines.) Steve Summit (talk) 21:15, 30 December 2005 (UTC)

Here's a next iteration:

C is a relatively minimalistic programming language. Among its design goals was that it be straightforwardly compilable — that is, that just a few machine language instructions would be required for each of its core language elements, without extensive run-time support. It is quite possible to write C code at a low level of abstraction analogous to assembly language; in fact C is sometimes referred to (and not always pejoratively) as "high-level assembly" or "portable assembly".
In part due to its relatively low level and modest feature set, C compilers can be developed comparatively easily. The language has therefore become available on a very wide range of platforms (probably more than for any other programming language in existence), and well-written C programs can therefore enjoy very wide portability.
C was originally developed (along with the Unix operating system with which it has long been associated) by programmers and for programmers, with few users other than its own designers in mind. Nevertheless, it has enjoyed very widespread popularity, finding use in contexts far beyond its initial systems-programming roots.

Steve Summit (talk) 21:15, 30 December 2005 (UTC)

Be bold and actually edit the article.
Done. :-) Steve Summit (talk) 18:24, 6 January 2006 (UTC)
Editing and iterating here before you edit is just duplication. Dysprosia 04:30, 31 December 2005 (UTC)
Well, intro edits can be controversial. But I like the changes. Deco 04:48, 31 December 2005 (UTC)
Well now wait one cotton picking minute! I have a serious objection to the following:
and well-written C programs can therefore enjoy very wide portability.
First of all, look in a dictionary for the definition of portable. This is a subversion of the usage of the word that is very C centric. This is not an article meant to only target people from the C community who already have ideas about the language. A Java-centric person would probably say something like "you can write code in C that works in many compilers, but the result is NOT portable from machine to machine". We're not barring Java-centric people from reading and understanding this article are we? Qed 19:07, 3 January 2006 (UTC)
In the mainstream computer science sense (and you can google on "define: portable" or see our own porting article to confirm this), "portable" means "can be recompiled with little or no change for another platform". The JVM notion of a binary that can be run on multiple platforms withut recompiling it is a whole nother kettle of fish. (Our stub machine-independent article is currently slanted towards that usage, though I think it could use some work, too.) But there's certainly no "subversion of the usage of the word that is very C centric" here. Steve Summit (talk) 19:29, 6 January 2006 (UTC)
Second, whether code is portable or not is no contingent on how well it is written. That's a subjective thing anyways. In any event, badly written code can be portable (gets() is available in basically all C compilers), and well written code may have limited portability (vsnprintf isn't even available on many compilers, yet its a very useful call that's hard to duplicate with other functions).
I would instead prefer the following language:
and portably written C programs can therefore enjoy wide availability.
This makes the therefore in the sentence more meaningful (as originally proposed, it is not correct to use therefore since the claim does not follow from what was stated earlier) and the sentence both more precise and more correct. Qed 19:07, 3 January 2006 (UTC)
I don't like the word "availability" there. It sounds like "there are many places you can get the program from" which is nonsense. What was meant is that a portably written C program can be run on more different kinds of computer than a portably written program in some language X which is such that fewer kinds of computer have X compilers than have C compilers. How about "a portably written C program can therefore be compiled for a very wide variety of computers"? DanielCristofani 03:05, 4 January 2006 (UTC)
Hmm ... I'm not sure I understand your objection, however your proposed change also seems acceptable to me, and in fact says even more (after all wide availability can also come from just supporting x86 on Windows alone). So I will endorse your version. Qed 18:08, 4 January 2006 (UTC)
Thank you. I just meant that "wide availability" and "widely available" usually describe something that can be acquired in many places, not necessarily something that can be used in many places. DanielCristofani 08:56, 5 January 2006 (UTC)
I stand by the sentence as originally wrritten, but the comments here are well-taken. I was talking about portability due not just to the wide availability of C compilers, but (perhaps even more importantly) to the portability-fostering aspects of the language itself. But I couldn't just say "C programs can enjoy very wide portability", because of course portability is not automatic, and it's just as possible to write rampantly non-portable C programs. Thus the "well-written" (where I tacitly assume that all agree that "portable" is one of the several programming virtues which travel under the rubric of "well-written"). [...]
Well, that's one problem. Especially when talking about C code, its not clear at all that "portable" and "well-written" are the same thing. If you made this absurd assumption you would have to conclude that every GUI application [...]
Please, there's no need for this extreme rhetoric. My claim was not absurd, as I certainly did not state that "portable" and "well-written" were the same thing. Also, you fall into a naive trap if you slide down a slippery slope and conclude that just because certain aspects of a program (e.g. its GUI) are system-dependent, the rest of it cannot be written portably. Steve Summit (talk) 10:09, 8 January 2006 (UTC)
...every application that was multithreaded, and even regular expression parsers (which needs to know the char representation of the system to correctly execute the "[X-Y]" range matcher) was not well-written code. For the C language, at best, "Well written" implying portability represents a particular point of view. Its not borne out by the reality of real world application development. Qed 23:36, 7 January 2006 (UTC)
Relax. The sentence in question did not say that (all) "well-written" programs are ipso facto portable, or that nonportable programs are therefore not well-written, nor indeed did it say anything about the sad reality of real world application development. Note that little word "can".
Yes, "Portably-written C programs can enjoy very wide portability" would have been more strictly accurate, except that it's then a ridiculous near-tautology. [...]
But that's all you have. You can say C is a language where its easier to write portable code than many of its predecessors (like Pascal, Fortran, etc) because the standard forces a common syntax for a certain set of implied functionality for the language. But in a modern context, or from the point of view of someone learning languages or having real application development needs today, C is NOT, relatively speaking, an appropriate language for portability. Comparing C to Python, Java or Lua, makes this point abundantly clear -- there is a level of portability assumed and delivered on by those languages that C does not. The main portability feature of C is that there is a common standard which implies a portable subset of functionality on all compliant compilers, but the language does not venture at all beyond this. So DanielCristofani's final revision of the comment is extremely accurate and appropriate: "a portably written C program can therefore be compiled for a very wide variety of computers". Qed 23:00, 7 January 2006 (UTC)
Anyway, the version I just posted is revised further to address these concerns. Steve Summit (talk) 18:24, 6 January 2006 (UTC)
Sorry, no. You put "availability" in there, but as DanielCristofani pointed out, it isn't the most precise consequence of the fact that many C compilers exist. I've changed it to a slight variation of Daniel's version (I added "standard's compliant", since that's the real prerequisite for C's asserted claim to portability).

Reversion

Stephan Schulz, why did you revert my entire edit instead of the one misguided change to the first example? --68.58.69.117 12:09, 3 January 2006 (UTC) (Random832, not logged in)

While the rest is not necessarily wrong (being speculative), it is still misleading. There is e.g. no guarantee that there even is an OS to return a value to (consider the difference between free-standing and hosted implementations). I also think that the return value of a program under some implementations is a very specific (and implementation-defined) point that just does not belong into this general example. --Stephan Schulz 12:37, 3 January 2006 (UTC)
OK - the point I was trying to make was just the fact that on many common implementations you get an incorrect value (13 on any intel x86 system, and for some reason 16 on PDP-11 unix (not exactly common, but the _first_ c implementation))
You do not get an incorrect value. You get an undefined value (that may, or (more likely) may not, be equal to EXIT_SUCCESS, which customarily, but not necessarily, is 0). And I bet you do not get 13 on any intel x86 system, either. It depends on your compiler and run time system much more than on your processor. Anyways, all this is very peripheral to C (the language), that's why I don't think it should be discussed in detail. Are you happy with my latest version?--Stephan Schulz 19:09, 3 January 2006 (UTC)

K&R Supplements

I removed two entries from the list:

  • Unique name space for each struct
  • Single point float data type

Both of these features appear in K&R. They might not have been in early versions of C, but by K&R's time, they were standard features. wrp103 (Bill Pringle) - [[User talk:Wrp103|Talk]] 01:48, 9 January 2006 (UTC)

Also, I seem to remember that K&R C would actually accept =+ as an operator for backwards compatibilty reasons, although it did produce a warning if you did something like a=+10, telling you to add a space to the statement. (This was the official compiler for AT&T Unix, which claimed to be K&R.) It is possible that it didn't actually support =+, but rather produced a warning message whenever it saw a construct that could have been meant as =+. What is clear, however, is that the =+ assignment operator doesn't appear in the K&R text. wrp103 (Bill Pringle) - [[User talk:Wrp103|Talk]] 20:47, 10 January 2006 (UTC)

explaining some changes

Someone at 217.247.66.87 "corrected some minor grammatical errors and made the wording cleaner" at 18:55 on 3 January 2006, but introduced a few errors in the process, which I'm correcting. A few of the corrections may seem subtle, so I'll explain them here:

the programmer can override the checks in various ways, either... or by using pointers or unions to reinterpret the underlying bits of a value in some other way.

That is, if you want to inspect (say) a float value as a series of raw bytes, one way is certainly to use union of a float and an array of unsigned char, but another is simply to use an unsigned char pointer:

        float f;
        unsigned char *p = (unsigned char *)&f;
        int i;

        for(i = 0; i < sizeof(f); i++)
                printf("%02x\n", *p++);
...at compile time, a pointer variable's type includes the type of the data pointed to...

Yes, the pointer variable's type, not its value. (At compile time, pointers have no values.)

Text strings are commonly manipulated using pointers into arrays of characters.

When a string is manipulated as a char *, this is a pointer to a character, not a pointer to an array. But the character is almost always within an array of some kind, thus the word "into".

Declarations either declare or define new types...

This one's tricky to say right, and still isn't perfect. When we're declaring variables, we can distinguish between the definitions which allocate space and the declarations which merely access a variable (and its space) defined elsewhere. But there's also a third case (which our treatment, perhaps confusingly, presents first), namely a declaration which doesn't declare a variable at all, but merely introduces (or "declares", or I'd say "defines") a new type.

Variadic functions / Overloading

Isn't this just compile time method overloading? I've not heard of "Variadic functions". -- Tompsci 16:16, 16 January 2006 (UTC)

Perhaps you're more into C++? Variadic functions is how I always knew functions such as printf etc. Camillus (talk) 16:31, 16 January 2006 (UTC)
I have never programmed in C++, (IMO) it just seemed an awkward name, maybe a reference could be made to polymorphism for those readers who are better aquainted with Object Orientated languages (including C#)? Has the term been superceded? -- Tompsci 16:38, 16 January 2006 (UTC)
I'm not familiar with that term, but the content of the section looks fine. I had simply heard of them as functions taking a variable number of arguments. Typically, you would use the varargs function when working with them. wrp103 (Bill Pringle) - [[User talk:Wrp103|Talk]] 16:42, 16 January 2006 (UTC)
It's not a made-up term. It occurs in the standard, in the GCC documentation, and in other notable locations. It's also not at all the same thing as overloading - an overloaded function has multiple versions specialized to certain fixed numbers and types of parameters. A variadic function can take an arbitrary number of parameters of arbitrary type. Even in C++ there's no typesafe equivalent of variadic functions. Deco 21:20, 16 January 2006 (UTC)

Move "Philosophy" section up and rename?

Really accessible article. I think moving the "Philosophy" section up be the first section would greatly improve it. The material there expands on the lead and sets up the rest of the article much better than the History. --Tsavage 08:04, 23 January 2006 (UTC)

There's been some debate on the Java (talk) article about which section should appear first. It's mostly an argument between History and Philosophy. Generally speaking I think either way works pretty well. If there's not much resistance to the suggestion, I'd say go ahead and give it a try. --Flash 21:03, 23 January 2006 (UTC)
OK, I'll wait a bit and will do it if there's no more comment. For me, it's not a matter of format, it's simply what's easier on the eyes (user friendly :) as it were after the summary, for the no-background reader. The Philosophy section helps ease you into the rest, whereas History gets a bit specific and harder to follow right off the top. (In the current edit of Java, IMO, same difference.) In general, it's the news-style pyramid development thing, broadening from the highlights, which I think Philosophy does better... Thanks. --Tsavage 04:33, 24 January 2006 (UTC)
Which type of presentation is more appropriate for an encyclopedia, news-style or textbook-style? News-style favors leading off with Philosophy, or maybe even Usage (establishing how the language is significant right away, and capturing the attention of the casual reader before presenting the historical context); textbook-style favors leading off with History (establishing as much of a historical context as possible before presenting anything else).
In news-style, you have a fleeting audience whose attention will drift quickly, and you have to grab them right away with interesting, useful info. In textbook-style, you basically have a captive audience (i.e. They've been assigned to read about the subject, and they pretty much have to whether or not they find it interesting). Is an encyclopedia somewhere in between, or is it clearly one or the other? --Flash 15:22, 27 January 2006 (UTC)
I think philosophy should be first, but I would consider possibly intermingling them - a discussion of the people and processes behind C and their motivations. Deco 06:07, 24 January 2006 (UTC)
It's worth noting that what's currently called the "Philosophy" section was not too long ago called "Overview", until I rewrote its lead paragraphs and (somewhat inadvertendly) made them more philosophical, and then someone renamed it, and then people started rearranging it... Steve Summit (talk) 06:17, 24 January 2006 (UTC)
This is fun! ;) Yes, I didn't mention the section heading somewhat in deference to world peace, but, indeed, in this case, at least, "Philosophy" is a little...obscure, and "Overview" or similar would IMO be a little more descriptive (and generally inviting)... --Tsavage 06:34, 24 January 2006 (UTC)
I've been using "Philosophy" to encompass both "the ideas behind the language" and "the basic nature of the language". For most of the programming-language articles, there's enough overlap between the two to where it's impractical to have separate "Philosophy" and "Overview" sections (respectively). Plus it might confuse people a bit if both sections existed for an article. I chose the term "Philosophy" rather than "Overview" thinking that it'd be a term that could be more widely applied, that could cover more ground, but it was a somewhat-arbitrary choice. --Flash 18:17, 24 January 2006 (UTC)
So, I just did the switch, putting Philosophy first. I don't see the pressing need to change the section title from Philosophy. That's really it for me. I was checking this article out as part of a Featured Article survey I started, and that was the main thing I noticed... As one additional comment, IMO, the Philosophy section is almost at the point of being "widely accessible" (lots of people will understand it), but I don't think it's there yet. As it is now, many readers will glaze over. Explaining in a little more plain English the what and why of C (just an adjustment to what's already in the Philosophy section) would make this article hugely better. Thanks. --Tsavage 02:43, 25 January 2006 (UTC)
No. No. History should almost always come first. History shapes the philosophy of the language. The article should be ordered to reflect this. Dysprosia 13:42, 25 January 2006 (UTC)
See also: related Java discussions. --Flash 15:57, 25 January 2006 (UTC)
This being a general encyclopedia, I think that making the entire article understandable to "most readers" is main thing. I read the discussion from Java talk mentioned above. In general, I agree with the idea that the primary article about a current language should be about what it IS more than where it came from. Of course, history is part of that story, but it isn't necessary to explaining what C is. So, the Philosophy section (which could also called Overview, or Design, or such) should be an extremely accessible introduction to what it is, why it was developed, where it fits among other languages. I don't suppose it matters what the section is called, as long as that info is included first, so that a context is developed. Points summarized in the introduction should be more fully developed before getting into other details, for example:
  • one of the most widely used programming languages
  • prized for its efficiency
  • the most popular programming language for writing system software
  • commonly used in computer science education, despite not being designed for novices
Here, History doesn't do that (Philosophy doesn't either, but comes closer). History, after the Space Travel legend, gets pretty murky. By the K&R C subsection, you definitely need some computer background to make sense of things. At that point, the "average reader" is likely...lost. IMHO. :) --Tsavage 02:58, 26 January 2006 (UTC)
I think what you listed above is a good outline for the Usage section. --Flash 18:02, 26 January 2006 (UTC)
If History is inadequate in some fashion it should be rewritten to improve flow. Arbitrarily reordering sections is not the best way of proceeding. Dysprosia 11:01, 27 January 2006 (UTC)

pointers

"Pointers are a primary source of danger."

Instead of begining the introduction about pointers with such a -ve note, cant we say that pointers are very powerful and then mention this? I do agree that if you use pointers the chances of your program crashing is more :) , but you cannot imagine a world without pointers, i think we can be a little more +ve here --vineeth 17:57, 27 January 2006 (UTC)
The section starts out with this because it's a subsection of the "Criticism" section, intended to describe features in a critical light. I can very well imagine a world which does not give you access to raw pointer arithmetic, unsafe pointer type conversion, and conversion from integral to pointer types at every place in an application when only a tiny fraction of places need these features (besides the common case of array indexing). See pointers in the Cyclone manual for Cyclone's many types of pointers intended to address these issues. A world without references of any sort would be dismal indeed, but pointers are far more dangerous than any reasonable application requires. Deco 19:36, 27 January 2006 (UTC)
I think a "potentially" needs to be in that sentence as well. Yes, they are "dangerous", but they are not universally dangerous. Dysprosia 05:32, 28 January 2006 (UTC)
Dangerous implies potentially. If it weren't potentially, it would be harmful, not dangerous. But if you want to tone it down that's fine. Deco 09:12, 28 January 2006 (UTC)
I don't know, I would interpret dangerous as "even with proper use, things could go wrong". I'll make an edit. Dysprosia 09:56, 28 January 2006 (UTC)