C is a better language than any language you care to name.
-
OriginalGriff wrote:
but they can't interpret what the author is trying to get the hardware to do and that means what they generate can be spectacularly inefficient.
I agree, I love programming in Assembly, but I'm not sure I would beat the compiler, I'm just an enthusiast, don't program in it professionally. I also love C/C++ and was wondering if the ARM compiler you used support mixing up C and Assembly, like:
__asm
{
INC [EAX]
MOV EBX, [EAX]
...
}To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
Yes: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205j/Cihccdja.html[^]
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
Yes: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205j/Cihccdja.html[^]
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
Awesome, thanks
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
-
Roger Wright wrote:
Then came C, and the death spiral of useful language development began.
It's like just as soon as computers get faster, we want to make the languages more bloated. That way we never enjoy the new speed, we simply keep things the same and have a new cool shiny layer that sounds technical to toss on top of it. I've never made a programming language, but when I think of something like Ruby, which has some nice features, and then I think it's slow as dirt so I'll never use it. Just because CPUs are faster doesn't mean we can waste cycles, otherwise it's always a game of catch up.
Jeremy Falcon
Jeremy Falcon wrote:
Just because CPUs are faster doesn't mean we can waste cycles, otherwise it's always a game of catch up.
True, only if you're doing something extremely CPU-bound. However, the vast majority of current application are highly user-interactive, where , by far, the really speed bottleneck is the user.
Truth, James
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
Let's start with this. Name any other language other than C. But there's a catch: the language's primary implementation must not currently be in C. So Java, JavaScript, Python don't qualify since they're canonical implementation is written in C. Also, self-hosting doesn't count; in that case, it must not have been bootstrapped with C. I'll start -- Pascal -- first version of Pascal was written in Fortran. Next...
-
Roger Wright wrote:
Then came C, and the death spiral of useful language development began.
It's like just as soon as computers get faster, we want to make the languages more bloated. That way we never enjoy the new speed, we simply keep things the same and have a new cool shiny layer that sounds technical to toss on top of it. I've never made a programming language, but when I think of something like Ruby, which has some nice features, and then I think it's slow as dirt so I'll never use it. Just because CPUs are faster doesn't mean we can waste cycles, otherwise it's always a game of catch up.
Jeremy Falcon
Jeremy Falcon wrote:
just as soon as computers get faster, we want to make the languages more bloated. That way we never enjoy the new speed, we simply keep things the same and have a new cool shiny layer that sounds technical to toss on top of it
The assembly guys said the same thing of C. I'd be willing to bet the patch-cable guys said the same thing of assembly. Do you really want to program your current applications using patch cables? How about assembler? It isn't (or shouldn't) be about adding cool-sounding technical layers, each language evolution allows the computer to do more of the mechanical grunt work, freeing us to spend more time doing the creative part. I don't know about you, but I really appreciate that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Jeremy Falcon wrote:
just as soon as computers get faster, we want to make the languages more bloated. That way we never enjoy the new speed, we simply keep things the same and have a new cool shiny layer that sounds technical to toss on top of it
The assembly guys said the same thing of C. I'd be willing to bet the patch-cable guys said the same thing of assembly. Do you really want to program your current applications using patch cables? How about assembler? It isn't (or shouldn't) be about adding cool-sounding technical layers, each language evolution allows the computer to do more of the mechanical grunt work, freeing us to spend more time doing the creative part. I don't know about you, but I really appreciate that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
patbob wrote:
It isn't (or shouldn't) be about adding cool-sounding technical layers, each language evolution allows the computer to do more of the mechanical grunt work, freeing us to spend more time doing the creative part. I don't know about you, but I really appreciate that.
I totally agree with this, but only if the evolution gives us a real gain. Something like sugar coating at the price of performance I don't agree with. A legitimate paradigm shift I could understand.
Jeremy Falcon
-
patbob wrote:
It isn't (or shouldn't) be about adding cool-sounding technical layers, each language evolution allows the computer to do more of the mechanical grunt work, freeing us to spend more time doing the creative part. I don't know about you, but I really appreciate that.
I totally agree with this, but only if the evolution gives us a real gain. Something like sugar coating at the price of performance I don't agree with. A legitimate paradigm shift I could understand.
Jeremy Falcon
Jeremy Falcon wrote:
sugar coating at the price of performance I don't agree with
Often, what has appeared to me at first as a sugar coating, turns out to be a paradigm shift in thinking that I didn't grasp. Not always, but a lot of times.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
Visual basic 2013. It can utilize every C, C++, and C# library. Plus it looks pretty. For example the "with" operator is in Visual basic but is not in C.
-
C# is better because # is composed of four pluses, therefore 4 times better than C: ++ ++
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
No, it's because it is a half tone above C.
-
C# is better because # is composed of four pluses, therefore 4 times better than C: ++ ++
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
Ah, but you can optimize those pluses and make the # with only two distorted pluses.
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
As already noted, one can write terribly in any language, programming or "natural". If writing systems level code: C or C++ If writing business system code: Modern COBOL If writing science/engineering code: Modern FORTRAN. If a masochist (or given no choice): Assembler If writing modeling system: (Probably still) SIMSCRIPT If writing WEB pages: HTML/CSS, but many IDEs now available to make this easier. 50 years of programing using 30+ languages including BASIC, VB, JOVIAL, HAL, 15+ assemblers, PL/1, APL, ALGOL, C/C++, HTML, JAVA, PYTHON, PERL, etc.
Charles Wolfe C. Wolfe Software Engineering
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
Any time anyone thinks that one technology is "better" than another then first they need to define what "better" means. And since the statement doesn't limit itself to which other language is compares itself to it is going to fail because for any measurable attribute there is going to be some language which is in fact better than C.
-
Nemanja Trifunovic wrote:
char *p = "hello"; //pointer - no information about the dimension char q[] = "hello"; // array - contains information about the dimension
No the ARRAY does not. The declaration does and thus the precompiler) and sizeof(), but not the array itself. To illustrate, the function:
void _function(const char r[])
{
printf("%u\n", sizeof(r));
}Will print 4 or 8, depending on the size of a pointer, when you call
_function(q);. Added: Moreover, an optimizing compiler will likely pool both strings and use the same pointer for both operations (especially since it's clear they are both const.) Again, the sizeof() is handled by the precompiler, not at runtime.Joe Woodbury wrote:
The declaration does and thus the precompiler) and sizeof(), but not the array itself.
Rather certain that the precompiler is in fact part of the language since it is in fact part of the specification for the language. If you wish to another definition for "language" than the specification then you would need to provide one. And if one wants to be specific then at least in my edition of "C Programming Language 2nd Edition" the preprocessor is part of the main language definition (not an appendix) and the section specifically starts off with "C provides certain language facilities by mean of a processor". So if K&R thinks it is part of the language I am going to take their word for it. Or perhaps to put in in another perspective, 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". Thus it can't, again in a practical, real world way, be "better" than anything else.
-
Joe Woodbury wrote:
The declaration does and thus the precompiler) and sizeof(), but not the array itself.
Rather certain that the precompiler is in fact part of the language since it is in fact part of the specification for the language. If you wish to another definition for "language" than the specification then you would need to provide one. And if one wants to be specific then at least in my edition of "C Programming Language 2nd Edition" the preprocessor is part of the main language definition (not an appendix) and the section specifically starts off with "C provides certain language facilities by mean of a processor". So if K&R thinks it is part of the language I am going to take their word for it. Or perhaps to put in in another perspective, 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". Thus it can't, again in a practical, real world way, be "better" than anything else.
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.) -
Visual basic 2013. It can utilize every C, C++, and C# library. Plus it looks pretty. For example the "with" operator is in Visual basic but is not in C.
Colborne_Greg wrote:
the "with" operator
...is useless filth. X|
You'll never get very far if all you do is follow instructions.
-
Let's start with this. Name any other language other than C. But there's a catch: the language's primary implementation must not currently be in C. So Java, JavaScript, Python don't qualify since they're canonical implementation is written in C. Also, self-hosting doesn't count; in that case, it must not have been bootstrapped with C. I'll start -- Pascal -- first version of Pascal was written in Fortran. Next...
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.
-
Chris Maunder wrote:
Discuss.
Arrays decay into pointers.[^] X| Or, for more details: C's Biggest Mistake[^]
Bushwa! That is one of its greatest strengths! There were only three mistakes in C, and one was fixed in C89 (if I recall correctly). The other two continue to plague us.
You'll never get very far if all you do is follow instructions.
-
OK, I'll "bite". "C" is quite the most disastrous so-called "language"[1] ever to become popular. Why? It's total lack of marshalling over record boundaries in memory have cost the globe at least several 100 trillion dollars in viruses, damages, fornicate-ups, interminable repairs/patches, Trojans, injuries, deaths, et cetera. That alone is enough to relegate this incurable abortion of a syntactical nightmare to the bit-bucket, if not Spandau prison. Have at it, you "C" devils. ___________________________ [1] Designed for punch-card use, brevity & conservation of card-space were essential. It thereby became an impenetrably terse & line-break free mess. All calculated to save IBM punched cards. And the syntax is dangerously ambiguous, all over the shop. Don't get me started on the monumentally bone-headed notion that CASE statements should cascade through without a BREAK clause! I mean. What total idiot "thought" that this would be a great idea?
Michael Kingsford Gray wrote:
the monumentally bone-headed notion that CASE statements should cascade through without a BREAK
:thumbsup: Hear! Hear! That is (in my opinion) the very worst mistake in C.
You'll never get very far if all you do is follow instructions.
-
D language[^] is better. It combines the simplicity of C and avoids all the kludginess of C++ for the same elegance you see in C#. Plus...no *.H files or #defines !!!! :) Plus garbage collection!
DaveX86 wrote:
Plus...no *.H files or #defines
The can have my
# defines when they pry them from my cold, dead hands.You'll never get very far if all you do is follow instructions.
