If the difference between chrome 8.0 and chrome 7.0 were as big as that between firefox 3.0 and firefox 2.0, or between opera 10.0 and opera 9.0, then you'd have a point. But they're not.
Are you sure? Java runs on a number of microcontrollers that haven't bothered with a C implementation. It's a very rare system that would have C and not have at least C++/Java these days (since the cheapest way to get a C compiler for your new system is to write a gcc backend, and that gets you C++ and java for free). And since perl/python/C# have interpreters written in C, if you have C it's pretty straightforward to get them.
More to the point, while another system will have a C compiler there is no guarantee at all that your program will work correctly on it. Wheras with java/perl/python/c#, the same program works on any system.
No, I said that portability is not an advantage of C unless you're comparing to assembly language. Assembly aside, C is not substantially more portable than any other vaguely mainstream language language, and compared to many languages, it is substantially less portable.
Libraries can't give you everything - they can't modify the language syntax, for example, so you'll be forced to nest function calls to accomplish anything. And depending on libraries external to the language brings its own problems. Yes every language will be missing some things - but languages which include more useful things are better than those that include less.
This makes C "flexible" and "simple" in the same way that an empty lot is simpler and more flexible than a house. C-the-language may be simple, but actually solving a given problem in C is more complex than doing the same in anything else, because C forces you to absorb all the complexity of the problem yourself.
There may still be a few projects for which C is the best choice, but they're very, very niche. Claiming "portability" is a joke unless you're comparing to assembly language (which, to be fair, C is in much the same position as these days). As for efficiency, the performance advantage is slim-to-none compared to, say, java (a language I hate, but that's for another time), and would be dwarfed by the impact of any of the mistakes it's all too easy to make in C. For C to be the most efficient choice, the programmers would have to be good enough to write C and find the bugs (and such programmers don't come cheap), and yet a small gain in performance would have to be worth a huge cost in programmer productivity, meaning the cost of performance differences would have to be absolutely huge.
But everything in C is like that - you have to implement all the higher level functionality yourself. Sure, it's a full programing language, so you can implement functions to give you a decent language on top of it (though since you don't even have object methods the syntax is never going to be nice), cf Greenspun, but you'd be better off just using a better language to start with.
A trivial (but relevant) example for why is that g++ will output extra information needed to propagate exceptions correctly; if you have a function that calls a function in another module, there's no way for g++ to know that the other module will never throw an exception, so it still writes that code. Of course, for that particular thing there's a flag to turn it off, but there are other cases. (Or were, last time I benchmarked it, which was admittedly some years ago)
Shudder. Of course you'd put the loop in a function, but you still have to write it.
It's really not complicated
No, it's not. None of the individual things that C makes harder is, in itself, much harder than the higher level equivalent. But they all add up.
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.
Only if they came from somewhere fond of overengineering. Often such literals do belong in the code. Sure, I could have gone for a real-world problem, but they tend to be too long; at the other end of a scale, artificial examples like Knuth's "man or boy test" or Graham's "accumulator generator" make the difference clearer. But the hashmap literal is the most succinct example I have that comes directly from my own, real-world experience, and it tends to be the first thing I look at when learning a new language.
A group of my friends have been working (slowly) on such a project for a while now. Though it's pretty much ended up being a client-server RTS where everyone writes their own client.
Here's an industry related question, how does high frequency trading benefit the general public? The push towards regnms, the push towards faster and faster executions---how does all this benefit Joe Investor?
The prominence of HFT does two things. Firstly, it makes the market liquid and more efficient - the difference between the prices at which Joe Investor can buy or sell a stock is probably down to fractions of a penny. Which you don't notice on the individual scale, but it improves the functioning of the whole market.
Secondly, and this is the more controversial factor, it can make the market more sensitive. See the recent article about the chicago futures whatchumacallit - note that it started due to an actual owner of whatever the commodity was (lumber? I forget) wanting to offload $4B worth. The HFT algorithms got wind of it, the price dived down a ways, the seller lost a substantial amount of money, then the market realised it was essentially a fuss about nothing and the price recovered.
Now, you could say that the HFT guys turned the molehill into a mountain. But personally I'd prefer to hear about it when someone tries to sell $4B of what I was just about to buy on the cheap. Thanks to the HFT folks, now the market as a whole twitches, where previously it would be only the big, well-informed investment trusts who heard about it. Up to you whether you think that's better or worse.
"Valid" in what sense? The 0.999... is merely notation; it's entirely up to our definitions what it means. The only deciding factor is what's useful. We declare 1=0.999... (or rather, declaring that both are in fact just convenient notation for a dedekind cut) because we declare we're using the "real numbers" (a ridiculous term, but there we go), which form a consistent structure which is effective in modelling reality (e.g. geometry, probability...). If you want to construct another system that's fine, but you'd better come up with a consistent notion of what "the number closest to 1 without being 1." actually means (and even then you should probably use a different notation for it, to avoid confusion).
Most modern applications want higher level data structures and algorithms. Which, sure, you can implement in C, but when you do that your code becomes a lot harder to read. In a modern high level language a hash set literal looks something like { 123: 'foo', 456: bar}. In C I dread to think how many lines that would be; all the nice syntax has been used for lower-level things like arrays. Heck, even an object method call in C looks syntactically nasty.
the idea of a language which works well without knowing what you are doing is laughable to me. The illusion comes, for example, from languages where you can build a robust web server in five lines (or whatever)... yes, because it has a webserver built in! if you are going to do something besides say "run this program which was already written", then you need to understand logic and machines. There is no way around that.
By that logic there's no point in any programming language, we should just write in assembly - you have to understand the machine, there's no way around that.
C++ can be made as fast as C, don't deny it because I can write a C++ program that IS C.
Sure, but if you compile it with g++ you'll find it runs substantially slower than with gcc.
You say that like it's a bad thing. It makes them easy to e.g. debug. If you want obfuscation you should do that with a specialised tool for the purpose, not rely on your compiler to do it.
both suffer from ugly politics.
Perhaps, but the end result has been better; both have decent standard libraries and if not quite "write once, run anywhere" then pretty close, putting them miles ahead of C++.
Sure, but we have to leave it somewhere - there isn't enough fuel to send it back to earth or anything - and it's better if that somewhere isn't the L2 point, which is a small region with some nice properties for certain types of missions.
b) eliminating our chance at recouping and reusing the materials onboard?
If we're placing it in a known, stable retirement orbit we can always pick it up later if we need it - space being a vacuum there's very little difference between dumping and mothballing. I highly doubt the materials would ever be worth the cost to retrieve them, but if we're lucky we might want to stick it in a museum some day.
What could be more simple and general than the big bang? (Unless you mean the physical laws that caused the big bang, I guess, but even so, those laws won't invalidate the big bang as the mechanism for the CMB. Just like knowing how electricity works gives a deeper and more fundamental explanation for what happened when someone got struck by lightning, "they were struck by lightning" is still the reason why they died).
Walking off a cliff would be stupid, it it clearly observed that things fall.
It's been observed that things fall in the past. But that gives no a priori proof that you will fall if you walk off a cliff. Of course, every time we observe something it does fall, which means the simplest consistent explanation is that things always fall, independent of time - but the exact same thing is true, on a higher level, of the real theory of gravity. And doubting that falling was due to gravity would in fact lead to equally stupid mistakes, perhaps not while walking off cliffs but while trying to predict orbits or similar. The distinction you're trying to draw doesn't exist.
That's simply false; some programs do something, do it well, and know where responsibility is best handed off to another program. When was the last time ls needed an update?
Slashdot Mirror
+5 insightful? Seriously?
If the difference between chrome 8.0 and chrome 7.0 were as big as that between firefox 3.0 and firefox 2.0, or between opera 10.0 and opera 9.0, then you'd have a point. But they're not.
More to the point, while another system will have a C compiler there is no guarantee at all that your program will work correctly on it. Wheras with java/perl/python/c#, the same program works on any system.
No, I said that portability is not an advantage of C unless you're comparing to assembly language. Assembly aside, C is not substantially more portable than any other vaguely mainstream language language, and compared to many languages, it is substantially less portable.
This makes C "flexible" and "simple" in the same way that an empty lot is simpler and more flexible than a house. C-the-language may be simple, but actually solving a given problem in C is more complex than doing the same in anything else, because C forces you to absorb all the complexity of the problem yourself.
There may still be a few projects for which C is the best choice, but they're very, very niche. Claiming "portability" is a joke unless you're comparing to assembly language (which, to be fair, C is in much the same position as these days). As for efficiency, the performance advantage is slim-to-none compared to, say, java (a language I hate, but that's for another time), and would be dwarfed by the impact of any of the mistakes it's all too easy to make in C. For C to be the most efficient choice, the programmers would have to be good enough to write C and find the bugs (and such programmers don't come cheap), and yet a small gain in performance would have to be worth a huge cost in programmer productivity, meaning the cost of performance differences would have to be absolutely huge.
Because stories can't be told with video games, oh no. Video games are nothing but gimmicks and visuals.
But everything in C is like that - you have to implement all the higher level functionality yourself. Sure, it's a full programing language, so you can implement functions to give you a decent language on top of it (though since you don't even have object methods the syntax is never going to be nice), cf Greenspun, but you'd be better off just using a better language to start with.
A trivial (but relevant) example for why is that g++ will output extra information needed to propagate exceptions correctly; if you have a function that calls a function in another module, there's no way for g++ to know that the other module will never throw an exception, so it still writes that code. Of course, for that particular thing there's a flag to turn it off, but there are other cases. (Or were, last time I benchmarked it, which was admittedly some years ago)
Yeah, so something like
Shudder. Of course you'd put the loop in a function, but you still have to write it.
It's really not complicated
No, it's not. None of the individual things that C makes harder is, in itself, much harder than the higher level equivalent. But they all add up.
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.
Only if they came from somewhere fond of overengineering. Often such literals do belong in the code. Sure, I could have gone for a real-world problem, but they tend to be too long; at the other end of a scale, artificial examples like Knuth's "man or boy test" or Graham's "accumulator generator" make the difference clearer. But the hashmap literal is the most succinct example I have that comes directly from my own, real-world experience, and it tends to be the first thing I look at when learning a new language.
A group of my friends have been working (slowly) on such a project for a while now. Though it's pretty much ended up being a client-server RTS where everyone writes their own client.
The prominence of HFT does two things. Firstly, it makes the market liquid and more efficient - the difference between the prices at which Joe Investor can buy or sell a stock is probably down to fractions of a penny. Which you don't notice on the individual scale, but it improves the functioning of the whole market.
Secondly, and this is the more controversial factor, it can make the market more sensitive. See the recent article about the chicago futures whatchumacallit - note that it started due to an actual owner of whatever the commodity was (lumber? I forget) wanting to offload $4B worth. The HFT algorithms got wind of it, the price dived down a ways, the seller lost a substantial amount of money, then the market realised it was essentially a fuss about nothing and the price recovered.
Now, you could say that the HFT guys turned the molehill into a mountain. But personally I'd prefer to hear about it when someone tries to sell $4B of what I was just about to buy on the cheap. Thanks to the HFT folks, now the market as a whole twitches, where previously it would be only the big, well-informed investment trusts who heard about it. Up to you whether you think that's better or worse.
"Valid" in what sense? The 0.999... is merely notation; it's entirely up to our definitions what it means. The only deciding factor is what's useful. We declare 1=0.999... (or rather, declaring that both are in fact just convenient notation for a dedekind cut) because we declare we're using the "real numbers" (a ridiculous term, but there we go), which form a consistent structure which is effective in modelling reality (e.g. geometry, probability...). If you want to construct another system that's fine, but you'd better come up with a consistent notion of what "the number closest to 1 without being 1." actually means (and even then you should probably use a different notation for it, to avoid confusion).
Most modern applications want higher level data structures and algorithms. Which, sure, you can implement in C, but when you do that your code becomes a lot harder to read. In a modern high level language a hash set literal looks something like { 123: 'foo', 456: bar}. In C I dread to think how many lines that would be; all the nice syntax has been used for lower-level things like arrays. Heck, even an object method call in C looks syntactically nasty.
By that logic there's no point in any programming language, we should just write in assembly - you have to understand the machine, there's no way around that.
C++ can be made as fast as C, don't deny it because I can write a C++ program that IS C.
Sure, but if you compile it with g++ you'll find it runs substantially slower than with gcc.
You say that like it's a bad thing. It makes them easy to e.g. debug. If you want obfuscation you should do that with a specialised tool for the purpose, not rely on your compiler to do it.
both suffer from ugly politics.
Perhaps, but the end result has been better; both have decent standard libraries and if not quite "write once, run anywhere" then pretty close, putting them miles ahead of C++.
But every time it comes up, it turns out opera actually has that feature built in.
They're approximations, sure. But very good ones. And all that was being assumed was that they "even remotely approximate" the real universe.
The question you have to ask yourself is if the Universe can have a description which is isomorphic to reality, but still different.
No. If it's isomorphic then it's the same in every meaningful sense; that's what isomorphic means.
But a model that is isomorphic to reality is not the same as reality.
Why? What's the difference?
But what about the knowledge you gain of mac internals, and the pleasure of putting something interesting together?
Nothing on the web needs doing.
a) just cluttering up the wider solar system
Sure, but we have to leave it somewhere - there isn't enough fuel to send it back to earth or anything - and it's better if that somewhere isn't the L2 point, which is a small region with some nice properties for certain types of missions.
b) eliminating our chance at recouping and reusing the materials onboard?
If we're placing it in a known, stable retirement orbit we can always pick it up later if we need it - space being a vacuum there's very little difference between dumping and mothballing. I highly doubt the materials would ever be worth the cost to retrieve them, but if we're lucky we might want to stick it in a museum some day.
Who says we're replacing with a monoculture? Let the market be split between five or six different systems, then everyone'd be a lot better off.
I thought it was using thrusters to stabilize its orbit. In which case, no paradox.
What could be more simple and general than the big bang? (Unless you mean the physical laws that caused the big bang, I guess, but even so, those laws won't invalidate the big bang as the mechanism for the CMB. Just like knowing how electricity works gives a deeper and more fundamental explanation for what happened when someone got struck by lightning, "they were struck by lightning" is still the reason why they died).
It's been observed that things fall in the past. But that gives no a priori proof that you will fall if you walk off a cliff. Of course, every time we observe something it does fall, which means the simplest consistent explanation is that things always fall, independent of time - but the exact same thing is true, on a higher level, of the real theory of gravity. And doubting that falling was due to gravity would in fact lead to equally stupid mistakes, perhaps not while walking off cliffs but while trying to predict orbits or similar. The distinction you're trying to draw doesn't exist.
That's simply false; some programs do something, do it well, and know where responsibility is best handed off to another program. When was the last time ls needed an update?
Another relevant factor is that it made it onto the first page of the EU settlement browser selection thing.