I suppose it depends on your perspective. Obviously many orders of magnitude more useful code has been written in COBOL and C++ than in Smalltalk and Lisp. If the designers of COBOL and C++ set out to make languages that other people could use, then they succeeded spectacularly.

11 years ago pg's audience was much smaller, internet culture was blunter, a good flame war was appreciated, and the term troll wasn't bandied about quite as freely.

No, he's right. Now, Java is not such a terrible language. On a 1-to-10 scale, it's a solid 5. (5.01? Can I make that joke?) It's unpleasant and verbose, but the early Java community had real language designers, and even some heavyweights, behind it (including Odersky, designer of Scala) and believe me, they've made more good decisions than bad ones. (Language design is hard, yo.) They got Unicode right in a time where expert language designers had their heads in the sand on that one (UTF-16 is annoying, but it's a hell of a lot better than byte arrays and strings living in the same type.) However, Java was inevitably hijacked by the "commodity programmer" culture where businessmen make decisions based on risk-limiting amid mediocrity rather than clearing barriers and allowing excellence (as well as a few non-starters, cf. Paul Graham's notion of "Black Swan Farming") to shine. It's not a fun language to use, and the community that has grown up around it since its inception has shown bad taste (J2EE, Maven, Eclipse). But for a period of about a decade, Java was the best (if not only) choice for a variety of problems.

Also, Java managed to succeed in the enterprise by feasting on Cobol's corpse, but it built up a Detroit: a good-enough but unattractive infrastructure that thrives when people have solid economic reasons to care about it, then is abandoned rapidly when the context changes.

Groovy, Scala, and Clojure came out of an interesting insight: there's some stuff in the JVM ecosystem that's too valuable to abandon just because the Java language is (albeit slowly) dying. It'll be interesting to see how these languages evolve in the next 15 years. Clojure is (IMO) the best Lisp, and Scala is exciting as well... but there's a lot of cultural legacy to deal with (there's plenty of bad Scala code being written by recently-promoted Java programmers; most of them will improve massively as they get a hang of the language, I hope.) Step 1 is to either improve or fire the FactoryFactory crowd in its entirety.

Java got unicode horribly, horribly wrong; assuming everything will be in the BMP is like assuming everything will be ascii, only harder to spot in testing.

It got some things right; threading (even ten years on Java has a more reliable thread model than tcl/perl/python/ruby), strong typing (not much use day-to-day, but incredibly valuable for building extensible libraries that can nevertheless be evolved without breaking existing code), maven.

I think it achieved the enormous success it has mostly by being a conservative, incremental improvement over C++ and Cobol. A lot of things introduced in later versions of java were things other languages had been doing for years, but an unwillingness to adopt unproven techniques is the best thing about java. I don't think it even is the best choice for any given problem - it's just that in a real world of mediocrity and turnover, java makes it possible to produce reliable, boring code with minimal risk.

The unicode consortium got unicode wrong, not java. At the time Java was created, there only was a BMP and Unicode had a purely 16-bit design. Therefore, it was perfectly reasonable for java to assume a 16-bit char. Unicode was later extended to support more than 2^16 characters, but that was after java was created, hence the need for UCS-2/UTF-16

Other languages which strongly value backwards compatibility and were created around the same time have the same issue - e.g.: C#/.NET, i believe python as well

Java got some basics very, very wrong. First-class object iteration, list comprehension, string manipulation...either these features are nonexistent or feature brutal syntax bordering on the hideous C++ container class verbosity.

I think the introduction of lambdas will ease the pain with the first two. That is, we can add weak syntactic support for first-class iteration and list comprehensions -- both are monadic features, and though Java can't express a general monad, it can bolt the monadic features on as a design pattern. So none of it will be pretty, but it'll be better than the current situation.