This is exactly what needed to be said, and repeated until it is fully and widely understood. Cognitive dissonance should not be assuaged at the cost of the rational and empirical.
If you actually want to affect a change with communication it's useful to think through what, where and how you say it. But mostly, don't just complain, include a patch. E.g. our Ruby and RoR patches were accepted the same day with gratitude: http://blog.pluron.com/2008/01/ruby-on-rails-i.html
We (Pluron/Acunote team) are going to be presenting @ RailsConf 2009 ( http://en.oreilly.com/rails2009/public/schedule/detail/8615 - Advanced Performance Optimization of Rails Applications ) and it's going to take some work to frame the presentation in a useful fashion. As tempting as it is just to point out how bad every single part of the stack is, from our hosting to Firefox, it would be highly misleading; they are still the best available options.
Having said that, it's a pleasure to have HN where these sensitive topics can be discussed in a rational fashion.
The suggestion to provide patches is a simple displacement mechanism. A correct, reasoned evaluation is not predicated on also including patches, and a reasoned evaluator may have significant cause to not invest further effort in providing improvements to the evaluated software.
That said, I don't think the right solution to avoiding problems like this is a "head in the sand" approach. If there are real performance issues, they should be acknowledged and addressed. I definitely get the sense that a lot of Ruby zealots are trying to pretend that there is no problem, which is something that Java zealots tried to do years ago (and something that the people in control of feature requests still do quite a bit, using the "Nobody can microbenchmark the JVM, it's too smart!" excuse).
I don't know why this stuff gets people so emotional, though. You don't see carpenters have heated arguments about whether a screwdriver is better than a hammer; why do programmers get so emotionally attached to their tools, refusing to acknowledge the limitations and strengths of each particular one?
Edit: I am specifically thinking about Ruby here. It seems quite neat and worth trying, but... Maybe I'm spoiled with polite communities.
Required effort causes programmers to know less languages and to value the languages they already know higher as they've had to come up with a rationalization for learning the language. This rationalization hinders acknowledging the downsides of the languages they've learned.
Additionally, languages give us our vocabulary and solutions seen beautiful by a programmer of one language can seem incomprehensible or at least ugly to programmer of another language. This is at least something that I've personally observed in a Java-shop I work in.
Sadly, there's no standard and acknowlegedly forceful way to say: "Your statement is technically veridical but I disagree with the connotations you intend to sneak in."
My language is powerful; yours has dynamic binding; his is slow.
Yeah, there is. You yell. That's why cable TV news shows (and politics in general) suck so much -- you get two sides who refuse to actually contradict each other competing on volume to have their message triumph over the other.
That's because most of the people watching are going to come away with one idea, and you want those people. If you want to "win" in the minds of those simple-minded people, and your opponent isn't saying something that can be easily falsified, you have to compete on volume, arrogance, and ferocity.
On the other hand, if you only care about the viewers or readers who are capable of having a nuanced view, you can simply say what you have to say, as clearly and cogently as you know how. They'll understand and remember. But will you really be satisfied with those people? Probably not, if you're fighting for votes or market share. In other words, unless all you want is a fair shake from intelligent people, what you want can't be had in a civil way.
By accusing people of "cognitive dissonance" and apparently believing that's the primary issue here, you are contributing to the drama.
See the comments on the original:
http://www.radicalbehavior.com/5-question-interview-with-twi...
The aggressive and insulting remarks directed at Ruby, Rails and people associated with them are exactly the source of the problem here.
What I've seen of C# 3.0 and F# also implies that those languages could meet this criteria, but my experience with them is limited.
Are you saying that fortran isn't faster than scala/jvm based languages? That APL isn't better for matrice's? That lisp macros aren't more powerful? Or that php isn't simpler than scala?
Being good at all three may be possible, but being optimal at all three is probably impossible.
Why?
Note "conflicting objectives". Why do you believe the objectives are conflicting?
If you wonder why there's a firestorm, it might be because of sweeping generalizations.
Your final example of development time is wholly unrelated to runtime implementation performance, and its use as a justification to assuage cognitive dissonance is predicated on a false dilemma -- that a language can not both support rapid development and a well performing runtime.
It is not necessary to introduce a false dilemma to justify an individual preference for Ruby development, in spite of its measured performance.
There's a selection bias here. If you write your compiler or interpreter or pathfinding algorithm in Python, it's going to be a lot more than 10× slower than if you wrote it in C (or Java or OCaml or whatever). So people don't write those programs in Python, so we don't get to compare them.
I've been writing about Python because I know more about it than I do about Ruby, but I think most of the same things are true of Ruby, as well.