Recognize that languages have goals and communities. It helps to evaluate them in that context. Features that are high priority to you may not be high priority to the majority of users in that language.
Recognize that many smart, capable people are very productive in the language you're slagging. The cool things science and industry are making in the language speaks far louder than your casual dismissals of it on a message board.
The same logic goes for language developers. For example, Hadley Wickham is a smart guy and a great programmer; he's probably not one to waste his time improving a language that's some irreparably broken dead-end. Same with these guys.
Recognize that language design is the art of the tradeoff. Don't complain about a design choice until you understand the logic behind it. In many cases, your preferred design or feature was already considered, and would have led to undesirable outcomes elsewhere. It is helpful and interesting to disagree about how a tradeoff was managed, but do recognize that there was one.
Distinguish between a feature request and a language critique. If you come to a new language and miss some features of your old language, that's fine. But that's not necessarily a failing of the new language.
A language, as it lives, is a combination of its features and its idioms. A feature may not exist because its programmers tend to write code in a way that obviate its need.
Pay your dues before dismissing a language. If you gave up on something in a language after finding it too difficult, consider that the problem may be yours. It may not be, but at least consider it.
Don't over-sell immature, alpha-version features, no matter how promising they are. Promises don't cook rice. Sending unsuspecting users to buggy, incomplete libraries just harms your cause in the long run.
Examples:
- "Julia has a fast-growing library of packages!" Sure, but less than a handful are close to production quality.
- "And now ggplot has been ported to Python!" Not quite yet.
Honest advertising of works-in-progress is encouraged, though. There's nothing inherently wrong with immature libraries, many of which are fantastic.
Microbenchmarks are useful for understanding differences between languages their execution, but are of limited use in pissing contests. No one knows exactly what percentage of the world's working software is comprised of Fibonacci number calculations, but our best guess is not much.
Whether one language is going to take over another is not that interesting, nor that meaningful. (When does a language get "taken over?" For Christ's sakes, there's still a non-trivial amount of COBOL running out there in the wild.)
Competition is pointless, but comparison is not. Languages are increasingly adopting ideas from each other, building interops with each other, and sharing tooling. Having conversations about this process is far more interesting than running popularity contests.
Avoid clichéd arguments. They are not necessarily incaccurate, but they are boring.
Examples:
- R is a "DSL" or "not a real language" (see Article 2 below); R is "designed by statisticians, not computer scientists."
- "Semantic whitespace in Python sucks." (Generally, arguments over syntax are boring.)
- "Julia doesn't have as many libraries as ${pretty much anything}."
In addition to arguments, also avoid clichéd phrases. (See, e.g., "not ready for prime-time.")
Supplement abstract terms or subjective impressions with concrete definitions and examples.
Examples of statements that could use concrete support:
- "Code in language X is more expressive than language Y."
- "R is a DSL, while Python is a general purpose language."
Be sure that you can accurately summarize someone's argument before you start composing your rebuttal.
You are not so smart that you are entitled to be smug. Some tips:
- Nix hyperbolic vocabulary. No one and nothing associated with any language is "stupid," "dumb," "crazy", "broken," etc.
- Use of the word "fail" is strongly discouraged. Use of it as a noun is strictly prohibited.
- It is no victory--not even a moral one--to find someone wrong on the internet. Don't treat it a such. Offer a polite factual correction and allow for the possibility that you've misunderstood.