C is a better language than any language you care to name.
-
Have you read the article?
Colborne_Greg wrote:
It can utilize every C, C++, and C# library.
C can be plugged into any application in any language. The author is aware that C itself lacks libraries and he does mention it. So what was your point again?
Colborne_Greg wrote:
Plus it looks pretty.
Ah that. :doh: Ok, seriously. If you meant it has a better readability, that was mentioned by the author, too. So, again the question, what was your point?
Colborne_Greg wrote:
For example the "with" operator is in Visual basic but is not in C.
And it's in Pascal. So what? Again, the author made a point that other languages offer more (and often more complex) language elements - but that doesn't deterr him from listing a number of advantages of the language C that you failed to address entirely. Disclaimer: I don't actually agree with the article. I just wanted to point out that the article already pointed out or implied everything you said, and you did nothing to argue against it. (if that was your purpose)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
Your signature has a line about GOTO The goto fail example is a major fail in general for the C language. The goto is the first thing every programmer should avoid, but in this example the GOTO's are used correctly, but its a limitation of the C language (one of the dumbest things in history I might add) Visual basic .net is C with English words and no bracket issue, the GOTO fail would never had been an issue in VB.
-
reflection ???!!! :confused: :omg:
You'll never get very far if all you do is follow instructions.
Interesting that your signature is "You'll never get very far if all you do is follow the instructions" fitting for this tread isn't it
-
You are arguing against something I never said. Specifically, nowhere did I say that the precompiler isn't part of the language. More generally, my point is that the information about the size of the array is known only by the scope of the array declaration at compile time; it is not contained in the array itself and available at runtime. In C, an array and a pointer are, for all intents and purposes, synonymous (with the exception of this very narrow edge case.) So, the [partial] function declarations
a(const char* p)andb(const char d[])mean the same thing. Doing asizeof(d)for the latter doesn't tell you anything meaningful about the original array. This also means that you can take an arbitrary pointer and use array syntax on it. i.e.p[3]. This gives C an enormous power and flexibility found in few other languages. Attaching any other information to a pointer (or array) changes the very nature of what a pointer is and adds overhead that is often not desired nor wanted (and if desired, you can easily create a struct (or class in C++) with that information contained in it. This very flexibility means that arguing that arrays are problematic in C is a strawman argument.) -
jschell wrote:
Rather certain that the precompiler is in fact part of the language
Yes, and as he said in his response, he didn't say otherwise. Some points I'd like to make are: A language is defined by its compiler (not the other way around). DMR probably could have made C without a pre-processor; I see no reason that C has to have a pre-processor other than that it does have a pre-processor. The existence of D and C# may support this view. I have seen (I don't remember where) at least one argument that the C pre-processor acts on a different language than the C compiler does; and I am in about 90% agreement with that point of view. I like the C pre-processor; it's really just a text processing utility -- it can be used for purposes other than its primary usage. (I even use it with C# -- Implanting Common Code in Unrelated Classes[^]) Unfortunately, it also has some functions (e.g. sizeof) that are tightly bound to C. :sigh:
jschell wrote:
limiting oneself to just the "language" then C is in fact useless, since one cannot in any practical way do anything useful with the "language"
You may be arguing that the language is pretty limited without libraries, and that is quite true, very little can be accomplished without at least printf -- I have written a simple program that calculates a value and returns it from main, simply to demonstrate that something, no matter how pointless, can be done without linking in any libraries. However, I think the article was also pointing out the ease with which a developer can leverage a multitude of libraries with C. Just the other week I was playing with ODBC, and linking in only the ODBC libraries and not the "standard C libraries". Of course, doing so still requires the pre-processor, as the Creator intended.
jschell wrote:
I am going to take their word for it
Soooo... if Microsoft says that VB is the World's Greatest Language.... ? :suss:
PIEBALDconsult wrote:
A language is defined by its compiler (not the other way around).
No. Compiler theory is a very complete area of study in computer science and most perhaps all successful languages build upon that. And within compiler theory the compiler is an implementation, nothing more. And in terms of C, although perhaps not specifically this discussion, there are many ambiguities which the compiler is allowed to define but others which it is not.
PIEBALDconsult wrote:
I like the C pre-processor; it's really just a text processing utility -- it can be used for purposes other than its primary usage
With something like 20 years of C/C++ experience I am pretty comfortable with what the language is and isn't.
PIEBALDconsult wrote:
and that is quite true,
As I said.
PIEBALDconsult wrote:
Soooo... if Microsoft says that VB is the World's Greatest Language....
Well first I was noting a technical point not a subjective one. Second K&R when it was written was written in a different style than VB, so even if the author(s) of VB made a technical point then I would be less inclined to accept it (which is true of C# and Java as well.)
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
-
Your signature has a line about GOTO The goto fail example is a major fail in general for the C language. The goto is the first thing every programmer should avoid, but in this example the GOTO's are used correctly, but its a limitation of the C language (one of the dumbest things in history I might add) Visual basic .net is C with English words and no bracket issue, the GOTO fail would never had been an issue in VB.
You've completely missed my point. My sig should have made it obvious I abhor the use of goto. I merely pointed out a possible reason why
casemay have been specified the way it is. Not that I wouldn't like to bangotofrom the language entirely. And not that I would miss theswitchstatement for that matter (not much anyway). It was just a statement about the consistency of the language as a whole. As for your love of Basic - to each their own. It certainly has it's use for certain kind of applications. Me, I've been working on processing-intensive applications for decades, and no Basic dialect whatsoever, not even the compiled ones, would ever have served the purpose. That said, I'll remove the link from my sig: as you've pointed out, the main reason for the problem isn't so much the use of goto - it is the fact that braces (or other block markers) are only optional after control statements, combined with an unlucky duplicate line of code - that this line contains agotocommand is just happenstance, many other commands would have caused havoc as well. On a sidenote:Colborne_Greg wrote:
Visual basic .net is C with English words and no bracket issue, the GOTO fail would never had been an issue in VB.
Which part of
go toisn't english? Just wondering...GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
Maybe, but
breakdoesn't affect agoto. And I have never used agotoin C.You'll never get very far if all you do is follow instructions.
My point was that a series of
casestatements resembles a series ofgotojump labels, and therefore there is an expectation for the flow of execution to continue, even past the next 'label'. Thebreakcommand isn't associated to thecasestatement, it is associated to theswitchblock.GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
My point was that a series of
casestatements resembles a series ofgotojump labels, and therefore there is an expectation for the flow of execution to continue, even past the next 'label'. Thebreakcommand isn't associated to thecasestatement, it is associated to theswitchblock.GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote:
resembles a series goto
Not to me it doesn't.
You'll never get very far if all you do is follow instructions.
-
Kenneth Kasajian wrote:
Pascal
Aaaannnd... how do you work with very long strings? Very large structures*? * Maybe only a problem with Turbo Pascal with its 64K per structure limit.
You'll never get very far if all you do is follow instructions.
I think I may not have been clear in my point because I don't understand what you're asking me. I'm not saying Pascal is better than C or the other way around. I'm saying Pascal is a language that was not originally written in C. It was written in Fortran, after which it was bootstrapped to be written in itself.
-
Kenneth Kasajian wrote:
Pascal
Aaaannnd... how do you work with very long strings? Very large structures*? * Maybe only a problem with Turbo Pascal with its 64K per structure limit.
You'll never get very far if all you do is follow instructions.
Also to answer the more specific question, I don't think the language has anything to do with 64K limits, for strings, or otherwise. Those are all implementation details of specific compilers.
-
I think I may not have been clear in my point because I don't understand what you're asking me. I'm not saying Pascal is better than C or the other way around. I'm saying Pascal is a language that was not originally written in C. It was written in Fortran, after which it was bootstrapped to be written in itself.
It sure looks like you are proposing that Pascal is a better language than C, based on certain criteria. Pascal is indeed a very good language and I really liked it when I was using it in college, but I haven't used it since, and I can't even read/understand the code I have from that period.
Kenneth Kasajian wrote:
Pascal is a language that was not originally written in C
Nor was C.
Kenneth Kasajian wrote:
after which it was bootstrapped to be written in itself
As was C.
You'll never get very far if all you do is follow instructions.
-
Also to answer the more specific question, I don't think the language has anything to do with 64K limits, for strings, or otherwise. Those are all implementation details of specific compilers.
Kenneth Kasajian wrote:
implementation details of specific compilers
That may well be, but is it not part of the Pascal language spec that a string is limited to 255 characters because the length is stored in the first byte of the string? I suppose not every implementation uses 8-bit characters, but it still imposes a definite limitation other than "available system resources".
You'll never get very far if all you do is follow instructions.
-
It sure looks like you are proposing that Pascal is a better language than C, based on certain criteria. Pascal is indeed a very good language and I really liked it when I was using it in college, but I haven't used it since, and I can't even read/understand the code I have from that period.
Kenneth Kasajian wrote:
Pascal is a language that was not originally written in C
Nor was C.
Kenneth Kasajian wrote:
after which it was bootstrapped to be written in itself
As was C.
You'll never get very far if all you do is follow instructions.
No, you have completely missed the point of my message. Go back and re-read it. What I am saying is that, a lot of people bash C but those same people don't realize that whatever language they prefer is probably written in C. So I challenged the readers to name a language that was not written in C.. because it's hard to do. Most new languages, VB, JavaScript, Python, Ruby all written in C. However, there are languages not originally written in C, although they are old. Pascal is one, which is the one I mentioned to get the ball rolling. You're being unnecessarily antagonistic without understanding, or taking the time to read, what I'm saying. I suggest you drop it.
-
Kenneth Kasajian wrote:
implementation details of specific compilers
That may well be, but is it not part of the Pascal language spec that a string is limited to 255 characters because the length is stored in the first byte of the string? I suppose not every implementation uses 8-bit characters, but it still imposes a definite limitation other than "available system resources".
You'll never get very far if all you do is follow instructions.
Okay, although it's true that one can implement Pascal differently, you're right that it's limited to 64K (or 32K) in length for strings. But I really don't think that's a good example of Pascal's inferiority over C. There's advantages to counted-strings, and I've worked in environments where actually simulated Pascal strings in C for efficiency (i.e. you can easily get to the length). COM BSTRs use a similar structure, but store 32-bit lengths. And the reason I don't think it's a limitation is because if you needed a string that long, C's null-terminated string is hardly preferable. You likely need a different data-structure (rope, array of strings) to do whatever you're doing anyway. Or, more likely, it's that big, it's probably a memory buffer that you'd manage using address and count. As a reminder, my initial post was not stating Pascal is better than C. It was to point out that many of today's languages are written in C.
-
No, you have completely missed the point of my message. Go back and re-read it. What I am saying is that, a lot of people bash C but those same people don't realize that whatever language they prefer is probably written in C. So I challenged the readers to name a language that was not written in C.. because it's hard to do. Most new languages, VB, JavaScript, Python, Ruby all written in C. However, there are languages not originally written in C, although they are old. Pascal is one, which is the one I mentioned to get the ball rolling. You're being unnecessarily antagonistic without understanding, or taking the time to read, what I'm saying. I suggest you drop it.
Sooo... your post is totally unrelated to Chris' prompt for discussion of languages that are or are not better than C. OK.
Kenneth Kasajian wrote:
Go back and re-read it
I have read it many times, always in the context of the thread.
Kenneth Kasajian wrote:
a lot of people bash C but those same people don't realize that whatever language they prefer is probably written in C
So what?
Kenneth Kasajian wrote:
I challenged the readers to name a language that was not written in C
You could have made that clearer.
Kenneth Kasajian wrote:
not originally written in C ... Pascal is one
Pascal pre-dates C slightly, it certainly pre-dates C's popularity. COBOL, Fortran, and BASIC also pre-date C.
You'll never get very far if all you do is follow instructions.
-
Okay, although it's true that one can implement Pascal differently, you're right that it's limited to 64K (or 32K) in length for strings. But I really don't think that's a good example of Pascal's inferiority over C. There's advantages to counted-strings, and I've worked in environments where actually simulated Pascal strings in C for efficiency (i.e. you can easily get to the length). COM BSTRs use a similar structure, but store 32-bit lengths. And the reason I don't think it's a limitation is because if you needed a string that long, C's null-terminated string is hardly preferable. You likely need a different data-structure (rope, array of strings) to do whatever you're doing anyway. Or, more likely, it's that big, it's probably a memory buffer that you'd manage using address and count. As a reminder, my initial post was not stating Pascal is better than C. It was to point out that many of today's languages are written in C.
Kenneth Kasajian wrote:
I don't think it's a limitation
Perhaps you just don't find the limit to be a hindrance. I never had any trouble with it either, but I never had to use Pascal to do real-world development. Just as .net strings are limited to 2GB -- it's a limit, but it hasn't yet been a hindrance.
Kenneth Kasajian wrote:
C's null-terminated string is hardly preferable
They certainly have some disadvantages, but at least they're easy to work around.
You'll never get very far if all you do is follow instructions.
-
You've completely missed my point. My sig should have made it obvious I abhor the use of goto. I merely pointed out a possible reason why
casemay have been specified the way it is. Not that I wouldn't like to bangotofrom the language entirely. And not that I would miss theswitchstatement for that matter (not much anyway). It was just a statement about the consistency of the language as a whole. As for your love of Basic - to each their own. It certainly has it's use for certain kind of applications. Me, I've been working on processing-intensive applications for decades, and no Basic dialect whatsoever, not even the compiled ones, would ever have served the purpose. That said, I'll remove the link from my sig: as you've pointed out, the main reason for the problem isn't so much the use of goto - it is the fact that braces (or other block markers) are only optional after control statements, combined with an unlucky duplicate line of code - that this line contains agotocommand is just happenstance, many other commands would have caused havoc as well. On a sidenote:Colborne_Greg wrote:
Visual basic .net is C with English words and no bracket issue, the GOTO fail would never had been an issue in VB.
Which part of
go toisn't english? Just wondering...GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
I programmed Unidex in visual basic, there isn't a conditional statement involved in retrieving a value from a serialized file (no sql) it can handle creating 8 million records an hour, and can read 2.3 billion records an hour.
-
Stefan_Lang wrote:
resembles a series goto
Not to me it doesn't.
You'll never get very far if all you do is follow instructions.
Because you chose to ignore the part that I specifically underlined. I didn't say
goto, I saidgotojump labels - that is a world of a difference! How is the followingswitch(a) {
case 1:
...
case 2:
...
}different from
on a goto label1, label2
label1:
...
label2:
...? The multilabel
on ... gotovariant is present in many BASIC variants.GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I programmed Unidex in visual basic, there isn't a conditional statement involved in retrieving a value from a serialized file (no sql) it can handle creating 8 million records an hour, and can read 2.3 billion records an hour.
:zzz: You didn't get the point of anything I said. But nevermind. I've got it that you prefer VB from your first posting. That's fine. Have a nice day.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Because you chose to ignore the part that I specifically underlined. I didn't say
goto, I saidgotojump labels - that is a world of a difference! How is the followingswitch(a) {
case 1:
...
case 2:
...
}different from
on a goto label1, label2
label1:
...
label2:
...? The multilabel
on ... gotovariant is present in many BASIC variants.GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote:
you chose to ignore
I didn't ignore it; the CP selection quoting doesn't like to select text with tags in it and I was too lazy to copy the other text into the quote. Like this:
switch(a)
{
case 1:
{
...
}case 2:
{
...
}
}Stefan_Lang wrote:
is present in many BASIC variants
C probably pre-dates them, so perhaps the designers of those variants got the idea from C :-D . When I learned BASIC we didn't have labels, only line numbers.
ON a GOTO 100 , 200Also, the lines/labels could be anywhere, not grouped together as with CASE statements. Ergo, to me aswitchdoesn't resemble anON/GOTOat all. BASIC (1964) doesn't appear to have had ON/GOTO. BASICplus (that which I first learned on a PDP-11, and for which I have a book first published in 1976) has no labels and therefore ON/GOTO with line numbers only. Turbo BASIC (1987) has labels and therefore ON/GOTO with labels. In the late '80s I was using VAX BASIC and I don't recall it using labels, though it probably did. HPBASIC, the current version of VAX BASIC, does of course.You'll never get very far if all you do is follow instructions.