Yes. I didn't see a lot of equivocation there, so I didn't supply a lot in return. I apologize.
And I'm sorry if I have lost all patience with phrases of the form X is a slower language than Y. These catchphrases are everywhere, major technical decisions are often based on them, and they are often worthless. They are overgeneralizations.
To make such a statement meaningful, the least we need to know is: What problem did you try to solve? What languages did you compare? What frameworks, compilers, interpreters, libraries, helper applications, and/or platforms did you use? Can we see your code? And what are the numbers?
As Yehuda points out, when you leave these things out you end up with mindless 1-D generalizations like "Ruby is slow; ergo, all systems which have Ruby in them somewhere are slow". Which you never question or test. And then you mislead everyone. You even mislead yourself! And even if you happen to be correct, for a given problem on a given day, things can change by next week. For example: the Javascript interpreter folks are working wonders, speeding certain computations up by orders of magnitude. (The Chrome JS interpreter nearly made me weep with pure joy.)
I don't see how we're going to break people of this bad habit except by correcting them, one by one if necessary. We certainly won't learn from history: We went through all of this with Java, less than a decade ago. Java was famous for being "slow", until one day everyone realized that it wasn't "slow" anymore and that it hadn't been for a couple of years. Now people hold up the JVM as the canonical example of a fast thing! (And C, of course, is always assumed to be extra-fast -- as if every C routine in the world were written by Knuth himself, in flawless bug-free form, with optimum algorithms.)
All good points. I agree with the overgeneralizations, and usually just skip right over such simple statements.
Sounds like if you edited this comment, toned things down a bit, and added a solid conclusion, it'd make a good blog post. And a good starting point for informing discussion.
I see no need for an apology here. I should be the one apologizing for a poorly written comment. Fortunately it appears some good discussion has come of it.
Yes. I didn't see a lot of equivocation there, so I didn't supply a lot in return. I apologize.
And I'm sorry if I have lost all patience with phrases of the form X is a slower language than Y. These catchphrases are everywhere, major technical decisions are often based on them, and they are often worthless. They are overgeneralizations.
To make such a statement meaningful, the least we need to know is: What problem did you try to solve? What languages did you compare? What frameworks, compilers, interpreters, libraries, helper applications, and/or platforms did you use? Can we see your code? And what are the numbers?
As Yehuda points out, when you leave these things out you end up with mindless 1-D generalizations like "Ruby is slow; ergo, all systems which have Ruby in them somewhere are slow". Which you never question or test. And then you mislead everyone. You even mislead yourself! And even if you happen to be correct, for a given problem on a given day, things can change by next week. For example: the Javascript interpreter folks are working wonders, speeding certain computations up by orders of magnitude. (The Chrome JS interpreter nearly made me weep with pure joy.)
I don't see how we're going to break people of this bad habit except by correcting them, one by one if necessary. We certainly won't learn from history: We went through all of this with Java, less than a decade ago. Java was famous for being "slow", until one day everyone realized that it wasn't "slow" anymore and that it hadn't been for a couple of years. Now people hold up the JVM as the canonical example of a fast thing! (And C, of course, is always assumed to be extra-fast -- as if every C routine in the world were written by Knuth himself, in flawless bug-free form, with optimum algorithms.)