Yes, the guy is very clever at putting down things that he didn't really like. The phrase "damning with faint praise" comes to mind, but upon reflection it doesn't really apply in this case. He's really damning it with criticism badly disguised as praise.
Yes, I know that he says that he is negative and his praise comes across badly (he gives an example of him damning his blogging software). I suggest, if he is being sincere, that the problem is his attitude. If he isn't being sincere, then I'd say that he's not as clever as he thinks he is, or he just never had any passion for Java and so he actually hates it as he never mastered it.
In terms of boilerplate code, I'd love to see his exact examples. With annotations, I've found that plenty of Java code is actually not verbose at all. If he churned out thousands of classes when actually he could have reduced the number of classes to 50, then that's an example of poor management and poor workmanship, certainly not a problem with the language.
Here's the real issue: the article conflates a corporate environment that likes to measure productivity in klocs (or from the number of classes you create) with the tool that is being used. He even admits that he could have actually produced better code, just that nobody cared to correct him when he produced crap quality code.
However, when it comes down to it, the real phrase that comes to mind is:
YHBT. YHL. HAND.
The guy is trolling you all.
(Different languages have different failure modes. With Perl, the project might fail because you designed and implemented a pile of shit, but there is a clever workaround for any problem, so you might be able to keep it going long enough to hand it off to someone else, and then when it fails it will be their fault, not yours. With Haskell someone probably should have been fired in the first month for choosing to do it in Haskell.)
The languages he praises so highly are now put down. Correction: in each case, he's dissing the programmers who wrote the crappy code and caused the project to fail, and he's damning the terrible management that didn't have good enough leadership and oversight to prevent the project failure.
>>In terms of boilerplate code, I'd love to see his exact examples.
Seriously, this is likely asking proof regarding the presence of sun during broad day light.
>>With annotations, I've found that plenty of Java code is actually not verbose at all.
Again. Are you really serious?
>>If he churned out thousands of classes when actually he could have reduced the number of classes to 50, then that's an example of poor management and poor workmanship, certainly not a problem with the language.
You certainly haven't ready his book 'Higher Order Perl'.
I find most annotations in Java are workarounds for missing language features. If you need a piece of functionality you're better off working in a language that provides it natively, so that all your tools will understand it.
> Seriously Clever for A 10 year old book on perl basics is probably pushing it.
Why is the age of this book relevant? It's not an overview of the basics. it's a 500+ page exploration of Perl's functional programming features, a topic rarely (if ever) covered in this depth.
Sometimes it is the tool that's to blame, you know.
Even the best master carpenter wouldn't be able to build something as simple as an end table if he were given a pickle to use as a hammer, and an onion to use as a saw.
The tool seemed to be the right tool or at least good enough for the master carpenters of Hadoop, Elasticsearch, Cassandra, Zookeeper, Neo4J etc etc... and Google, Netflix, Twitter etc etc...
That's a terrible analogy. More along the lines of using a sledge hammmer to crack a nut is probably more appropriate here. Java is very powerful but sometimes using it for very simple programs can be overkill
Also, have you heard the saying: A bad workman blames his tools
