This is out of line. You're making sweeping generalizations about Java programmers and likening them to peevish children playing in a sandbox. Sorry to be blunt, but you need to realize you shouldn't characterize programmers as "good" or "bad" on the basis of whether or not they use a language that includes a garbage collector.
You're absolutely right that these things are completely out of line, and all I can say in my own defense is that it's a good thing I didn't say any of them.
I do some work in Java myself. I know a great number of talented, skilled, experienced programmers, many more so than myself, who work primarily in Java. Maybe if I had said so explicitly in the first post you would have been inclined to read the rest more closely, so I apologize for that oversight. Those people are not remotely who I am talking about.
If there can be said to be a problem with Java itself in all this, it's the two-edged sword that it's a high-torque language. It allows novice programmers to accomplish a lot fairly quickly. It does, however, lead a great number of them to think they know very much more than they do, and when they run into situations not covered by their Java experience, they blame the tools for not matching their expectations. Many of them paradoxically cop this strange superior attitude on the basis of what they don't know, like their language makes them better for not having to know it. God knows computer scientists aren't known for their humility, but bragging about not knowing what your program is doing is beyond the pale.
To reiterate, I don't hold this attitude against Java programmers generally, but the attitude is common enough that there are those who do.
I only called out memory management specifically because it's the example I see most consistently. Really the debate about when one strategy works better than another is beside the point, because the point is that schools are turning out graduates with CS degrees who are unable to even have such a discussion to begin with. Again, calling a language bad or primitive because it doesn't have a garbage collector says more about the programmer than it does about the language.
And, again, for the benefit of those inclined to misread between the lines, I am not claiming that languages
with collectors are bad. I admit I don't care for being forced to use one, but they certainly can be useful. I actually really like the way Objective-C 2 has approached GC, and one of these days I'll get around to experimenting with it (perhaps using some of the time I otherwise use posting here, eh?).
It goes without saying, in most cases the standard memory management model is sufficient. Whether garbage collected or explicitly managed, allocation performance is not a bottleneck in most programming situations. When it is, though, it pays to know why such bottlenecks might happen in your given paradigm and what you might do differently to address it, whether you're talking about collection overhead in GC or heap fragmentation using malloc. That's the depth of skill a lot of the "only GC languages are good" crowd lack, and frequently seem
proud to lack.
