Did you really just say that C is as portable as Assembly language? Are you really unaware of the myriad of C libraries and other software which is multi-platform?
Not that that's the only great exaggeration you made during this argument.
What part of "use standard libraries" don't you understand? Every language is going to have things missing, with C you have the minimal stuff which always performs well in the language, and everything else is up to you.
I'm not saying you always need this flexibility, that's what other languages are for... Choose them for the projects that they make sense on, and admit that C is the best choice for certain kinds of programs. There's nothing that comes close to C in its combination of efficiency, simplicity and portability.
Shudder. Of course you'd put the loop in a function, but you still have to write it.
Yeah, once (or maybe zero times if you use an existing hash library). Of course you would make a function that could insert any number of elements. A handful lines of code, no big deal at all (certainly not big enough to dismiss a language)...
Ummm... just a simple array of structs { {123, "foo"}, {456, "bar"}, and then just make a function that adds each element to the hash.
It's really not complicated, and btw most reasonably big programs wouldn't have magic literals like that scattered through the code, instead they would be in a configuration or data file that the program loads to memory.
There are C++ IDEs that will do that for you and I have respect for the people that wrote them, because between the preprocessor and ambiguous syntax, parsing and analyzing C++ code reliably is nigh impossible.
True, IDEs make it a bit easier, but they can't solve all the cases, for example when a variable's derived type isn't known.
There are also other features of C++ that make it hard to read, like the possibility of passing arguments by reference to a function. It can be pretty confusing since you're never quite sure if a variable is getting changed just by passing it to a function. With C at least you would have to explicitly pass its address, which is an immediate tell that something is going on.
Using C because its "more efficient" is like making tons of micro-optimizations before you even know where your performance problems are.
No, it is not like that at all. Especially since C already gives you most of the features that make higher-level languages easy to use (variable names, records, control structures etc.). So you're getting more efficiency without making extreme efforts (unlike what your analogy would imply).
Just as early optimization is bad, I also consider early "pessimization" to be bad, and in many cases you already know from the start that your application will have to be efficient.
It just wastes time and means you eschew the use of more appropriate tools for the task at hand.
What makes you think that there are more appropriate tools for the task at hand? Sure, for some tasks there may be. But not for all tasks, and I think we're straying a bit from the original point which is that C can be nice to work with. No one's saying that it's always the best choice.
But I think a sensible language should at least try to discourage it.
I'm not so sure. Bad programmers always find ways to shoot themselves in the foot, no matter how much the language tries to cripple their efforts.
Could you explain concretely what you like about working with C?
I like working with C because it gives me almost all the performance of Assembly language and almost all (or for many applications, all) the ease-of-use of higher-level languages. It's also good to know that whatever new machines or architectures pop up tomorrow, there is bound to be a good C compiler for it, which is more than you can say about most other languages.
Just glad I don't need to read their code!
I don't see how well-written C code is so much harder to read than well-written code in Python, Java, or whatever...
So that's exaggerating a bit, but even if I enjoyed writing some C++ programs, I still find it hard to dive into C++ source code and understanding what it does.
For example... If you're reading a piece of C code and see a function call, you can find the function definition with a simple textual search. With C++ you have to look at the argument types (due to function overloading), you have to check what the object type due to derived classes, etc. What a mess it is just to find out precisely what code is behind a function call.
It's really a pain in the ass to read C++ code that you haven't written (or maybe even that you wrote some months ago).
The not-so fascist guard will hold the train open a door for her and let her on - an action that may delay trains for everyone for the rest of the day.
If a delay of a few seconds can cause cascading delays the rest of the day, the train system wasn't that good to begin with.
Exactly the same as getting cancer after choosing not to pay for health insurance.
Except cancer is usually not contagious, and a fire is definitely contagious. If the fire had quickly spread and completely destroyed a nearby house which had paid the fee, what would the firefighters say to the owner of this house?
Follow this argument for a while and the obvious conclusion is that you just can't have an optional fee for a service like fire protection. It doesn't work.
The problem with that thought experiment is that it's not true that Intel's 4 core CPUs beat equally priced AMD's 6 cores on heavily multithreaded tests.
Hyperthreading is a 10%-performance-boost thing in most cases...
beelsebob 4 hours ago: "the only place it claws anything back is in heavy multithreading tests where it can *just* beat the i3."
beelsebob a few minutes ago: "if you look at only the not-massively-parallel ones stays within 5% of the phenom."
Seems you're singing a quite different song now. Of course you had to, since the multi-threaded tests show a huge advantage (pretty obvious since we're comparing a quad-core vs a dual-core... hey it's not my fault, you were the one who brought the i3 into the discussion).
> A chip that need 6 cores to archive the same performance than one that has 4 is obviously technically inferior.
It achieves a higher performance on benchmarks that are actually using all of the cores. Obviously not many applications right now, but no one is exactly saying that everyone should go out and get a six core CPU. It's obviously a niche product right now.
Advanced Micro Devices said that its next-generation desktop processors code-named Zambezi will use socket AM3+ platforms, which will be backwards compatible with the firm's existing AM3 products.
It's from a month ago, do you have the link to the newer info?
That is just complete bullshit, Bulldozer will use AM3+ and probably be compatible with AM3 (just as the AM2+ CPUs were compatible with AM2 motherboards).
Slashdot Mirror
One day these physicists will find out too much and get our simulation shut down.
That could well happen:
WikiLeaks Leaks its Own Donors Due to Email Mishap
Mainstream programming languages (ignoring web server stuff): C++, Java, Perl, Python, C#, Visual Basic.
C is definitely available for more architectures and operating systems than any of these.
The home routers and modems don't support IPv6. Mine certainly doesn't, even though I got it quite recently from the phone company.
Did you really just say that C is as portable as Assembly language? Are you really unaware of the myriad of C libraries and other software which is multi-platform?
Not that that's the only great exaggeration you made during this argument.
What part of "use standard libraries" don't you understand? Every language is going to have things missing, with C you have the minimal stuff which always performs well in the language, and everything else is up to you.
I'm not saying you always need this flexibility, that's what other languages are for... Choose them for the projects that they make sense on, and admit that C is the best choice for certain kinds of programs. There's nothing that comes close to C in its combination of efficiency, simplicity and portability.
Yeah, once (or maybe zero times if you use an existing hash library). Of course you would make a function that could insert any number of elements. A handful lines of code, no big deal at all (certainly not big enough to dismiss a language)...
Ummm... just a simple array of structs { {123, "foo"}, {456, "bar"}, and then just make a function that adds each element to the hash.
It's really not complicated, and btw most reasonably big programs wouldn't have magic literals like that scattered through the code, instead they would be in a configuration or data file that the program loads to memory.
I have used those things when programming C++ and other languages, and I don't really miss them when I'm using C.
Those things aren't useful for every project.
True, IDEs make it a bit easier, but they can't solve all the cases, for example when a variable's derived type isn't known.
There are also other features of C++ that make it hard to read, like the possibility of passing arguments by reference to a function. It can be pretty confusing since you're never quite sure if a variable is getting changed just by passing it to a function. With C at least you would have to explicitly pass its address, which is an immediate tell that something is going on.
No, it is not like that at all. Especially since C already gives you most of the features that make higher-level languages easy to use (variable names, records, control structures etc.). So you're getting more efficiency without making extreme efforts (unlike what your analogy would imply).
Just as early optimization is bad, I also consider early "pessimization" to be bad, and in many cases you already know from the start that your application will have to be efficient.
What makes you think that there are more appropriate tools for the task at hand? Sure, for some tasks there may be. But not for all tasks, and I think we're straying a bit from the original point which is that C can be nice to work with. No one's saying that it's always the best choice.
I'm not so sure. Bad programmers always find ways to shoot themselves in the foot, no matter how much the language tries to cripple their efforts.
I like working with C because it gives me almost all the performance of Assembly language and almost all (or for many applications, all) the ease-of-use of higher-level languages. It's also good to know that whatever new machines or architectures pop up tomorrow, there is bound to be a good C compiler for it, which is more than you can say about most other languages.
I don't see how well-written C code is so much harder to read than well-written code in Python, Java, or whatever...
I like to work with C and I don't think any of that applies to me.
So that's exaggerating a bit, but even if I enjoyed writing some C++ programs, I still find it hard to dive into C++ source code and understanding what it does.
For example... If you're reading a piece of C code and see a function call, you can find the function definition with a simple textual search. With C++ you have to look at the argument types (due to function overloading), you have to check what the object type due to derived classes, etc. What a mess it is just to find out precisely what code is behind a function call.
It's really a pain in the ass to read C++ code that you haven't written (or maybe even that you wrote some months ago).
Might those "payments from Intel" be related to Intel's attempts to keep AMD CPUs out of the market place as much as possible?
If a delay of a few seconds can cause cascading delays the rest of the day, the train system wasn't that good to begin with.
Except cancer is usually not contagious, and a fire is definitely contagious. If the fire had quickly spread and completely destroyed a nearby house which had paid the fee, what would the firefighters say to the owner of this house?
Follow this argument for a while and the obvious conclusion is that you just can't have an optional fee for a service like fire protection. It doesn't work.
The problem with that thought experiment is that it's not true that Intel's 4 core CPUs beat equally priced AMD's 6 cores on heavily multithreaded tests.
Hyperthreading is a 10%-performance-boost thing in most cases...
beelsebob 4 hours ago: "the only place it claws anything back is in heavy multithreading tests where it can *just* beat the i3."
beelsebob a few minutes ago: "if you look at only the not-massively-parallel ones stays within 5% of the phenom."
Seems you're singing a quite different song now. Of course you had to, since the multi-threaded tests show a huge advantage (pretty obvious since we're comparing a quad-core vs a dual-core... hey it's not my fault, you were the one who brought the i3 into the discussion).
> A chip that need 6 cores to archive the same performance than one that has 4 is obviously technically inferior.
It achieves a higher performance on benchmarks that are actually using all of the cores. Obviously not many applications right now, but no one is exactly saying that everyone should go out and get a six core CPU. It's obviously a niche product right now.
> -the phenom wins in the multithreaded benchmarks, loses in all the less threaded ones
What do you mean by "all the less threaded ones", given that the phenom loses two or three benchmarks out of that whole list (at most)?
> Now lets look at the intel chip you claim that phenom is on a par with...
Seems much more even than the comparison with the i3 that you made...
I searched a bit and found this:
http://www.xbitlabs.com/news/cpu/display/20100826225852_Desktop_Bulldozer_Processors_Will_Require_New_Platforms_AMD.html
Advanced Micro Devices said that its next-generation desktop processors code-named Zambezi will use socket AM3+ platforms, which will be backwards compatible with the firm's existing AM3 products.
It's from a month ago, do you have the link to the newer info?
Intel only recently started using 32nm, most of their CPUs are still 45nm.
That is just complete bullshit, Bulldozer will use AM3+ and probably be compatible with AM3 (just as the AM2+ CPUs were compatible with AM2 motherboards).
You must be confused, or we're looking at very different benchmarks:
http://www.anandtech.com/bench/Product/102?vs=143