C is a better language than any language you care to name.
-
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
<sigh> We're all very impressed. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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!
Garbage collection is a flaw, not a feature. It not only sucks resources, it creates a huge unknown. Some of the most difficult problems I've dealt with were with garbage collection (in one recent case, we never did solve the problem--some the most brilliant engineers I know also failed to solve it. Around the same time, we tracked things back to a lesser known bug in the .NET 4.0 garbage collector.)
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
Chris Maunder wrote:
Discuss.
Arrays decay into pointers.[^] X| Or, for more details: C's Biggest Mistake[^]
-
You can write large scale, maintainable code in any language - even assembler! Conversely, you can also write small scale unreadable cr@p in any language (look at QA if you don't believe me) But...as the scale increases, it becomes easier to produce better code in an OOPs language, and harder in a non-OOps languages. It's like designing a car: you need to use powerful tools on a computer these days just to fit everything into the engine bay - you couldn't do it in a reasonable time frame using clay and palette knives!
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 – ∞)
OriginalGriff wrote:
ut...as the scale increases, it becomes easier to produce better code in an OOPs language, and harder in a non-OOps languages
It should be easier, but I've found it often gets much more difficult. Relatively recently I worked on a massive code base in OOP. There was nothing wrong with any single class or even the design, but as a whole, it was almost impossible to follow the whole thing. However, the sections that were pure procedural code or extremely lightweight classes were very easy to follow.
-
Chris Maunder wrote:
Discuss.
Arrays decay into pointers.[^] X| Or, for more details: C's Biggest Mistake[^]
What else would they do? As the article essentially points out, this is known. It's documented. There is no mystery.
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
-
OriginalGriff wrote:
ut...as the scale increases, it becomes easier to produce better code in an OOPs language, and harder in a non-OOps languages
It should be easier, but I've found it often gets much more difficult. Relatively recently I worked on a massive code base in OOP. There was nothing wrong with any single class or even the design, but as a whole, it was almost impossible to follow the whole thing. However, the sections that were pure procedural code or extremely lightweight classes were very easy to follow.
Joe Woodbury wrote:
However, the sections that were pure procedural code or extremely lightweight classes were very easy to follow.
I gotta agree with you there. OOP is nice, I like it. But on a massive scale it's like it almost adds too much complexity to track what goes where and really does what. Got nothing against OOP, it helps with clean code. But, I can still write a C program in large scale that's just as maintainable.
Jeremy Falcon
-
DaveX86 wrote:
Plus garbage collection!
As Is Well Understood and Universally Accepted: "You don't need garbage collection if your code is not garbage!"
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
W∴ Balboos wrote:
You don't need garbage collection if your code is not garbage!
Awesome!
Jeremy Falcon
-
Garbage collection is a flaw, not a feature. It not only sucks resources, it creates a huge unknown. Some of the most difficult problems I've dealt with were with garbage collection (in one recent case, we never did solve the problem--some the most brilliant engineers I know also failed to solve it. Around the same time, we tracked things back to a lesser known bug in the .NET 4.0 garbage collector.)
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
-
Chris Maunder wrote:
Discuss.
Arrays decay into pointers.[^] X| Or, for more details: C's Biggest Mistake[^]
Written by Walter Bright, who invented D and is still tilting at windmills over it. He's wrong. Arrays are pointers. Period. That's how they really are and to pretend they are something special or different is absurd. What's even more absurd is his claim that they "...and lose the information which gives the extent of the array - the array dimension." THEY NEVER HAD IT (unless a developer decided to make the array that way.) It's the very definition of a strawman argument. If you don't understand pointers, just say so and use a language "without" them (ha! all computer languages end up using pointers, they just hide them.)
-
Who's next? /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
No, who's on first...
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 – ∞)
-
Written by Walter Bright, who invented D and is still tilting at windmills over it. He's wrong. Arrays are pointers. Period. That's how they really are and to pretend they are something special or different is absurd. What's even more absurd is his claim that they "...and lose the information which gives the extent of the array - the array dimension." THEY NEVER HAD IT (unless a developer decided to make the array that way.) It's the very definition of a strawman argument. If you don't understand pointers, just say so and use a language "without" them (ha! all computer languages end up using pointers, they just hide them.)
Joe Woodbury wrote:
He's wrong. Arrays are pointers. Period. That's how they really are and to pretend they are something special or different is absurd. What's even more absurd is his claim that they "...and lose the information which gives the extent of the array - the array dimension." THEY NEVER HAD IT (unless a developer decided to make the array that way.) It's the very definition of a strawman argument.
Agreed! :thumbsup:
Jeremy Falcon
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
-
It's twice as good.
There are only 10 types of people in the world, those who understand binary and those who don't.
...and c# is pointedly better! Hmmm... that doesn't work, sharp ---> points... but there isn't much use of pointers directly so that may be a bad analogy and therefore an even worse pun! However, with puns, the worst is the best so, yeah! :-)
- I would love to change the world, but they won’t give me the source code.
-
It's a good language, but in the modern world it's a bit...outclassed. If you want small tight code for embedded work, then assembler is probably a good bet - though C is very useful there, it does tend to generate bloated code compared to that produced by a good assembler programmer. The C code will be produced faster, but it'll need more RAM, more processor, more...in embedded work you don't always have the luxury! If you want desktop work, then C# or C++ have so many massive advantages in terms of OOPs design that there really isn't any comparison. It'll take you a lot longer to write the same app in C, and it'll almost certainly be harder to maintain. If you want to write a website, then good luck doing it in C... It's a product of it's time: it was designed to be "better than COBOL and FORTRAN". But the world has moved on, and the "competition" is a lot more sophisticated now.
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 – ∞)
Quote:
"better than COBOL and FORTRAN".
Everything is better than COBOL but nothing is better than FORTRAN! Well... for maths stuff anyway! I wrote an expert system in FORTRAN-77, I thought it was so advanced now that I didn't have to pack characters two at a time into integers (FORTRAN IV).
- I would love to change the world, but they won’t give me the source code.
-
No, who's on first...
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 – ∞)
-
...and c# is pointedly better! Hmmm... that doesn't work, sharp ---> points... but there isn't much use of pointers directly so that may be a bad analogy and therefore an even worse pun! However, with puns, the worst is the best so, yeah! :-)
- I would love to change the world, but they won’t give me the source code.
-
Written by Walter Bright, who invented D and is still tilting at windmills over it. He's wrong. Arrays are pointers. Period. That's how they really are and to pretend they are something special or different is absurd. What's even more absurd is his claim that they "...and lose the information which gives the extent of the array - the array dimension." THEY NEVER HAD IT (unless a developer decided to make the array that way.) It's the very definition of a strawman argument. If you don't understand pointers, just say so and use a language "without" them (ha! all computer languages end up using pointers, they just hide them.)
Joe Woodbury wrote:
Arrays are pointers
Joe Woodbury wrote:
the information which gives the extent of the array - the array dimension." THEY NEVER HAD IT
char *p = "hello"; //pointer - no information about the dimension
char q[] = "hello"; // array - contains information about the dimensionprintf("%zu\n", sizeof(p)); // => size of pointer to char -- 4 on x86, 8 on x86-64
printf("%zu\n", sizeof(q)); // => size of char array in memory -- 6 on both -
Joe Woodbury wrote:
Arrays are pointers
Joe Woodbury wrote:
the information which gives the extent of the array - the array dimension." THEY NEVER HAD IT
char *p = "hello"; //pointer - no information about the dimension
char q[] = "hello"; // array - contains information about the dimensionprintf("%zu\n", sizeof(p)); // => size of pointer to char -- 4 on x86, 8 on x86-64
printf("%zu\n", sizeof(q)); // => size of char array in memory -- 6 on bothNemanja 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.
