It's slow and bloated. For someone who grew up coding intros and cracking protections in machine code on C=64 and the Amiga, such bloat simply won't fly. It's an abomination. I hate wasting my life away waiting for slow software.
If it makes you feel better, the JVM and dotnet communities agree and have been working on strategies to reduce the bloat a lot. They also offer a ton of other resources to help tune things to your liking.
I'm sure you can hand write a piece of C or Common Lisp that is very fast. But I'm sure you would also acknowledge that people that are good at JVM/Dotnet could probably write a pretty fast piece of code in them as well. So at a certain point you have to start weighing other things, like productivity, safety, tooling, libraries, etc.
I find if I really dislike something, I try learning it, and at the end I find that I may not prefer it, but I always learn something from the experience. Think of it as an exercise in sharpening your debate arguments against proponents of these platforms.
I had a semester of Java and AWT programming at the university. The professor was really good. My final project got a good grade. But after it was over, I knew I'd never touch Java again: any language where I needed to instantiate three different objects just to output a single message to the screen is crap.
Available libraries or lack thereof were never criteria by which I judge a language. Chalk that one up to competing against other coders on the scene. If someone disasembled one's intro code and found that one were using pieces of someone else's code, one instantaneously lost face and would never be able to live it down. It was plagiarism. 35 years later those same people still get derided and laughed at. It's considered extremely lame, because it means one wasn't capable of writing one's own routines. This is elitist in the extreme and those are the stakes for making it to the elite programming circle that is the scene. I'm perfectly fine with that, under the motto "it's lonely at the top". And that's as it should be. IT doesn't need more programmers producing so much bloated garbage; it needs the best programmers producing small, light and fast software that's a joy to use to its users.
So for me, having been tempered by such an elitist, competitive environment, library availability is never important. I understand that open source is different and I understand the advantage of not duplicating code, so if it's already been written and if it is good, clean code I'll use it, but I've no qualms about rolling my own.
I would never allow for library availability to influence my choice of a programming language: the language must stand on its own, including how easy it is for the system administrator to install and upgrade my application during its software managent lifecycle.
As programmers we should never make it easy or convenient for ourselves at the expense of complicating users' life or wasting their time. Never ever is that excusable.
This point of view seems to have a lot to do with programming as craft, and very little to do with programming as engineering.
Nothing wrong with that, but most developers are more concerned with the latter. Writing your own (compression routines|HTML parser|stepper motor driver|user interface controls|game engine) that's fast, cleanly designed, and bug-free is an act of craftsmanship. But if it takes a week and working around the quirks of one off the shelf takes an hour, and the resulting program meets the same requirements either way, it's the wrong engineering choice.
"But if it takes a week and working around the quirks of one off the shelf takes an hour, and the resulting program meets the same requirements either way, it's the wrong engineering choice."
(Un)fortunately, that's not how the world works: it never takes an hour to get the work done even with the off of the shelf solution, and software which gets put together this way usually ends up needing to be babysat and the long term costs to maintaining it are exorbitant. Curiously, the quality of the software ends up being extremely poor not because of using readily available components, but because of the mentality of the people springing for such solutions.
And somehow I have the impression that you and I have different defintions of "engineer": a programmer is not and never had been one. An engineer (which is what I do) gathers requirements, writes a technical specification based on those requirements, designs the software architecture which meets the specifications put forth, proceeds writing said software using scientific theories and principles (the actual process of engineering) and finally writes comprehensive documentation for that software.
