C is used for low level libraries for it's lean and mean performance. It sacrifices checks and safety features for this, and allows the programmer full control. Do you see professional race cars with ABS and Automatic Stabilization? No, you give the Driver FULL and TOTAL control, same with C and other low level languages. C has only a few data types that are as basic as you can get, I mean what do you expect use something like STL strings?
If you start having type checking and various other easy-to-code and child-safety features, you are bloating and giving up performance in the low level libraries, if this happens imagine what the performance on the higher up application level would be.
I'd prefer my libraries be rock solid secure even if I lose some (or even a lot of) performance for it.
Hardware is always getting cheaper.
Losing data integrity and the trust/confidence of your users is extremely expensive, and can be fatal for a startup.
Performance is not the most important metric for a lot of applications.
I'd prefer the safe but slow 5 star crash test rated sedan with a good alarm over the race car that is going to blow up after a few races, in library terms.
> I'd prefer my libraries be rock solid secure even if I lose some (or even a lot of) performance for it.
Then don't use C.
People don't seem to understand that C is just a step up from Assembly Language. There are no "types" in the sense that they exist in higher level languages. And thus, there are no ways to check those types (unless you want to write a type checking system yourself). Lets not forget that most modern programming languages with type checking and "rock solid secure" libraries were, in fact, written in C.
Which languages? SBCL is written in CL, GHC is written in Haskell, etc. Sure, there is some C to talk the C-based API of the OS it's running on, but all the important stuff is self-hosted. This is a rather common pattern, as nobody really wants to write important application code in C.
Please provide even a single deluded fantasy in which the price/performance ratio for a particular piece of hardware or component in the hardware stack will not continue to trend in the direction of more bang for the buck.
I don't know if this counts as "deluded", but how about: resource exhaustion of raw materials required in hardware manufacture.
See, for example: http://blogs.wsj.com/informedreader/2007/05/25/a-metal-scare... which talks primarily about LCD displays (we're fast running out of Gallium/Hafnium/Indium), but points out that copper is likely to get significantly more expensive throughout this century.
That's going to increase the price/performance ratio of practically everything.
Yep, that's a deluded fantasy all right. See "Ultimate Resource 2", "The Resourceful Earth", or "State of Humanity" by Julian Simon or "Earth Report 2000" by Ronald Bailey.
Silicon makes up much more of the cost of a computer than copper, its not even close. Silicon is >50 cents a gram, copper is less than a cent per gram.
That's what the significantly was all about. We're not really going to run out of silicon any time soon, but we actually might with copper.
At the moment, both those prices are strongly dominated by the cost of processing, I would imagine. At some point, it could well be the scarcity you're paying for with copper, though.
Scarcity increases price, and two orders of magnitude is hardly inconceivable.
"People always need a place to live so real estate/housing prices will always be going up. There is only a limited amount of land on the Earth, but the population continues to grow."
Yes, but I can't imagine any realistic scenario where this performance will start to backslide. The rate of performance increase will continue to slow down, and the number of cores that you get per unit will increase, but "the hardware" in the most general sense will keep getting faster and cheaper over time.
First, you said an upward trend - I submit that any meaningful upward trend in single core performance has ceased. Further, it has backslided in many cases. In order to increase the number of cores per processor, each core is getting simpler by reducing or eliminating single-threaded optimizations like branch prediction and out-of-order execution.
Actually, c-strings are a speed-for-memory trade-off. At the expense of saving a few bytes of memory per string, most operations are O(n) time (strlen, for example). If c-strings were in the form of <length><data> instead of <data><\0>, this bug would be avoided.
This is not a performance issue, only bad design and convention. (The other problem was using memcpy and strcmp on the same data. You can't treat blocks of memory as strings; a type system would eliminiate this confusion at no runtime cost.)
I think the cooking analogy holds. Sure, those people DO use knife-proof gloves and for good reason. They need to be able to cut through things of the same basic structure as human meat! So it goes with code: if you are working on a low level libs and languages you should be protecting yourself with well thought out data and exception handling. If you don't, you might just cut your hand, I mean, data off!
If you start having type checking and various other easy-to-code and child-safety features, you are bloating and giving up performance in the low level libraries, if this happens imagine what the performance on the higher up application level would be.