Though his definition of success seems to be "would really good programmers (wizards) ever use this language for sweet projects? If yes, than this language is a success." By that metric I guess he would be correct.
Basically for the niche that Java fits in (networked, multi-threaded data-center applications where performance is important), it hits a sweet spot of ease-of-development compared to performance. C++ is a nightmare to code in, comparatively, and the scripting languages are either dog slow, have poor concurrency support or both. YMMV I guess.
People think that languages like Python and Ruby are "cooler" somehow than Java - that's all I was trying to get at.
I don't think that I was making any judgments about the validity of that opinion, but I would say that it is fairly pervasive for better or for worse, and for many of the reasons that PG alluded to.
Really? I'm so out of touch. I always put Java down as something to use when performance wasn't important.
The computation was really quite simple, but it had to be done a bajillion times. I suspect part of the reason that it was so slow is that the JIT was not inlining something it obviously should have. However, I was unable to find any tools that would help me figure out if that was the case or what the JIT was actually achieving (consulting with Java experts I know didn't give any insight or link to such tools).
If you're telling yourself that "java is good for hi-performance computing", you aren't really concerned with speed or memory.
The bigger problem is that there's no reasonable way of figuring out what the problem might be.
And for the record, said code was a tight loop, created no objects, had the same kind of workload of a sort algorithm; The two nontrivial things about it was that it was accessing multiple simple vectors using the same index (non-idiomatic java), and that one of those vectors was a memory mapped buffer (non-idiomatic java, but essential because of the overuse of memory).
Once HotSpot kicks in, it's a different story.
You can write corporate drone type stuff in any language -- and you can write awesome code in any language. Java with a lot of immutability, closures (anonymous classes) and ExecutorServices is like a syntactically weird multi-threaded lisp. Very elegant. The language itself has something like 15 keywords, total.
As the person said upthread, you can look at some horrible 2002 EJB webapps (and I'm sure you can find their equivalents in rails), or you can look at projects like Hadoop, Hbase, Cassandra, etc. In general, static languages are probably a bad idea for webapps or scripting -- that doesn't mean they're the province of drones.
You don't see C++ programmers making thousand-line XML-based build files, or creating FactorySingletonFactoryVisitors.
I also don't agree with his criticism of Ada. Yeah, Ada isn't a good choice if you're building a web app that needs to be out next week. But Ada wasn't ever intended to be used for that sort of software. Ada was designed to build absolutely reliable software. I'd rather have the Space Shuttle's control software written in Ada than Java.
That's what I was thinking, too. Was Ada really meant for "other people" to use? I wonder how many people involved in the process went on to write Ada afterward?
I don't know the facts, but I would guess that the critical system software writers in the US are a fairly small group, and anyone on that committee knew they would end up writing a lot of Ada afterward.
I doubt it was the same kind of "make a language for the masses" simply because there aren't masses of people capable of writing software for critical systems. I would guess that it had more to do with a mutual pact: programmers have to add extra annotation for interfaces and constraints; but in return they can absolutely rely on those interfaces and constraints because they know that the compiler enforces them.
Of course, anyone who has worked the civilian side of DoD knows how bureaucratic it is, and I think pg is right to say that if DoD likes it, it's probably not a great sign. For instance, you can't submit invoices (you have to use a convoluted procurement application and enter it through a very 90s looking app). There are paperwork mandated by Congress and administrative agencies (GSA). And let's consider the Goliath that is DFAS. They use Oracle. And Oracle Forms.
I think Java's influence on Clojure is fairly small, and mostly visible around the places where the Clojure has to interoperate with Java libraries. I'm not sure what to call this - incidental influence, maybe?