I disagree with this. The argument seems to be that the only valid reasons to discredit a language are extrinsic to the language itself. Granted, one should always take into account the language's problem domain and design principles before criticizing for lacking X or having X, but this doesn't mean that the language itself can be poorly designed or have issues.

Java really is verbose. Perl really does have an inconsistent syntax. C++ really does lend itself to memory errors.

Do each of these languages solve the problem that they were meant to solve? I think so. Do each of them still have issues that deserve criticism? Of course.

I think that there is nothing wrong with criticizing a language. If we didn't criticize nothing would improve and there's always room for improvement.

The author seems to want to say that language features are invalid criteria on which to judge the quality of a language (instead, he suggests that you should look at the quality of the documentation, the libraries, the community, and perhaps the syntax).

It's true that there are some language features, like type checking and memory management, on which reasonable people disagree. I think that those represent opportunities for innovation. Type inference, for example, seems to be changing the terms of the debate about static vs. dynamic typing.

I think of it more like this: a programming language's features are like its genetic code. A dog is not a "bad" cat, it is just a dog. Nothing more, nothing less. A cat is badly suited for some dog-like tasks (dogsled racing), while a dog is likewise badly suited for some cat-like tasks (hairball production).

However, there are some ways in which a dog can be badly designed. It can be prone to cancer or congenital diseases. It may be blind from birth. Such things are not features of dogs, but rather extrinsic properties, just as the ones listed in the article.

Or, to put it simply: it is not what you do, but how you do it.

I think it's fair to look at language features as benefits and drawbacks in languages, as long as you're aware of what those features have to offer, and what the costs are.

It makes sense to want a way to judge languages not on the presence or absence of particular features, but on their ability to achieve some goal. But what should the goal be? Popularity? Lowest time required to write programs, or to read them? Approachability for new users, or convenience for experts? Utility for writing fast programs, or for writing programs fast?

You can specialize languages down to the point where there's a different best answer for every possible goal, but because I don't want to maintain fluency in 50 different languages, I'm most interested in languages that do very well in a wide variety of ways. If you want to get down to figuring out where the trade-offs really are, and which goals can be achieved simultaneously, you can't take the attitude that every language is just great at being itself. You have to allow for the possibility that some languages really would be better all around with the addition or alteration of certain features.

Lack of closures is hardly an "invalid" reason to dislike a language, especially if the reason for lacking closures is that they're too confusing for less-skilled programmers.