Cliff Click

The criticism of Java language is very much to the point (re: verbosity, inheritance). There's some confusion where he calls anonymous classes implementing interfaces "abstract classes with virtual methods"; that's not to say that it's not an awkward approach to closures and function pointers. There's also criticism of synchronized and the Thread class, but there's no mention of the strong points (Doug Lea's java.util.concurrent).

However, the criticism of JVM seems like it's written in 1999 about the Blackdown JVM (Josh Bloch in his interview in Coders At Work attributes much distrust of Java earlier on at Google to experience with this platform). Hot-spot can, many times, be within 10-15% of C's performance. In many cases code running on the JVM will outperform C++'s runtime (and particularly boost).

That's not to say there aren't issues: garbage collection pauses, the stack based nature -- rightly -- is pointed out as an impediment, but it's odd that LLVM isn't mention. However, excluding JVM due to performance (especially when used with modern languages, e.g. Scala, Clojure, Ruby, Javascript) seems short-sighted. See Cliff Click's post on JVM performance:

http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html

Repeat after me: HotSpot is not Blackdown, 1.5+ is not 1.2 (you have non-blocking I/O -- even though NIO is still painful to use, you have autoboxing, you have foreach, you have -- for all their limitations -- generics, you have…

Interesting, I haven't gotten to hear the thoughts of too many other telecom engineers when it comes to next generation languages and threading. I'm pretty convinced it has to be one of the hardest problems to get right.

Speaking of STM and locks, have you seen this epic debate?

http://blogs.azulsystems.com/cliff/2008/05/clojure-stms-vs.html

The problem with telecom software (that I'm dealing with now, in my very humble opinion), and the reason it hurts my head, is because you're essentially dealing with a distributed system, each leg being a node
(since each action a leg takes needs to go out over the wire). Not only do you need to see consistent 'state', you also need to make sure your actions are handled correctly as well.

"Sometimes no-warmup is important (see comments above about pacemakers), but more often a short warmup period is irrelevant to the overall application. If I'm using an IDE, I expect a largish loading period... but then I'm using the IDE all day. I don't use an IDE for 0.1 sec. If warmup is NOT important to the application, then allow the JVM a warmup period before comparing performance numbers. Many of the benchmarks in the language shootout at http://shootout.alioth.debian.org fall into this camp: too short to measure something interesting. Nearly all complete in 1 minute or less." http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html

OK, let me try to be more helpful. Here's good backgrounders

http://www.tbray.org/ongoing/What/Technology/Concurrency/

http://www.sauria.com/blog/2009/10/05/the-cambrian-period-of-concurrency/

http://groups.google.com/group/clojure/browse_thread/thread/5c7a962cc72c1fe7?hl=en

http://blogs.azulsystems.com/cliff/2008/09/jvm-language-su.html

http://wiki.jvmlangsummit.com/pdf/36_Click_fastbcs.pdf

---------------------

also recommended: Herlihy/Shavit book, blogs by Sutter and Duffy,

http://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0123705916

http://herbsutter.com/

http://www.bluebytesoftware.com/blog/Default.aspx

http://anarchaia.org/

http://blogs.azulsystems.com/cliff/ (JVM hacking, concurrency, non-blocking hashtable)

http://osteele.com/ (javascript, functional programming)

http://glinden.blogspot.com/ (personalization, collective intelligence)

http://paulbuchheit.blogspot.com/

http://steve-yegge.blogspot.com/

For the impatient, here's a pastebin with the actual code:

http://java.pastebin.ca/1298391

A followup article to this one includes a link to his sourceforge project:

http://blogs.azulsystems.com/cliff/2007/04/nonblocking_has.html