3 ms·

Wow, talk about strawmen: > for a large, complex application a good GC will be more > efficient than a zillion pieces of hand-tuned, randomly > micro-optimized

Wow, talk about strawmen: > for a large, complex application a good GC will be more > efficient than a zillion pieces of hand-tuned, randomly > micro-optimized storage management vs: > Note that I said a good garbage collector. Don't blame > the concept of GC just because you've never seen a good > GC that interfaces well with your favorite language. Ok, so we're comparing 'state of the art GC' to 'zillion pieces of hand-tuned, randomly micro-optimized storage management'. Astoundingly, we come to the conclusion that GC Is Awesome and MOAR Efficient.

pjscott 15y ago
In other words, he's comparing what we're likely to get with a large C project and what we're likely to get in a modern garbage-collected environment. I don't think he's claiming more than that; where's the problem?
- wladimir 15y ago
  Having practical experience working at a company that has a large number of developers trying their stab at C, I'm bound to agree. It's clear that you can make great code in C, if you're a good programmer and get enough time to plan things like memory management done right. Enough examples of that. But when you don't, C is a terrible language. It is very verbose, it makes you repeat yourself and the macro system is so error-prone to the point that it's usually forbidden to use. So you have to resort to custom code generators (we have at least three!). Most companies don't want to be in the business of worrying about buffer overflows and memory leaks and segmentation faults. They want the requested functionality implemented robustly ASAP. If there is less code to be written, there is less to test and worry about, so a high-level language that takes those concerns (largely) away is a great help. So my advise would be to limit using C to the performance-critical parts (found using benchmarking), and only make developers work on that which understand every detail about C. Also, give them enough time to test every nook and cranny threefold.

pjscott 15y ago

In other words, he's comparing what we're likely to get with a large C project and what we're likely to get in a modern garbage-collected environment. I don't think he's claiming more than that; where's the problem?

wladimir 15y ago
Having practical experience working at a company that has a large number of developers trying their stab at C, I'm bound to agree. It's clear that you can make great code in C, if you're a good programmer and get enough time to plan things like memory management done right. Enough examples of that. But when you don't, C is a terrible language. It is very verbose, it makes you repeat yourself and the macro system is so error-prone to the point that it's usually forbidden to use. So you have to resort to custom code generators (we have at least three!). Most companies don't want to be in the business of worrying about buffer overflows and memory leaks and segmentation faults. They want the requested functionality implemented robustly ASAP. If there is less code to be written, there is less to test and worry about, so a high-level language that takes those concerns (largely) away is a great help. So my advise would be to limit using C to the performance-critical parts (found using benchmarking), and only make developers work on that which understand every detail about C. Also, give them enough time to test every nook and cranny threefold.