From: Dave Howell Date: 2006-06-02T07:56:10+09:00 Subject: Re: Speed of Ruby program != Speed of Ruby language (was Re: Zed and Luis drop the bomb on Ruby's poor performance) On Jun 1, 2006, at 14:59, James Britt wrote: > Interesting. You assert this to be a nearly nonsensical argument, yet > you describe yourself as hobbyist programmer, and say that, for you, > the speed concerns are amusingly irrelevant. That's correct. I'm sure it's an error on my part to assume that you're implying that the fact I don't find Ruby too slow for my own needs somehow makes me incapable of logical thought. > >> That might make my *program* run faster, but it didn't do >> diddly-squat for making *Ruby* faster. > > Do you use the YAML parser in Ruby? No. > Or the String class? Yes. > They're C. I find that assertion to be quite ludicrous. A C string is a null-terminated byte sequence. I've happily never had to use to any great extent any other language that didn't effectively insulate me from any need to track the terminal null (the vast majority don't even *use* that, but rather store the length as an integer at the front of the string), or that allowed my code to inadvertantly overwrite the terminal null, thus turning a string into an object of indefinite length, sucking down whatever random bytes lay beyond the end of the actual string bytes until it found some other "00x0" in memory. The String class is not only nothing like a C string, it's not a string at all, in the sense that any/all other languages I've met use the term. It's an Object, and that makes it act in ways fundamentally different than the strings I've met in SQL, AppleScript, Modula-2, Pascal, or Basic (various dialects, all with line numbers), to name a few. > Ruby and C are old friends. If you really want to know Ruby, you need > to know at least some amount of C. You're going to have to provide some rather compelling evidence before I give that opinion much credence. Ruby and Perl are "old friends," too. Nevertheless, if there are aspects of Ruby that came from these languages, and I cannot learn them directly and exclusively via Ruby, that just says to me that the Ruby documentation still needs work. When I decided that AppleScript (XCode and AppleScript Studio notwithstanding) were inherently inadequate for the programming I wanted to do, I selected Ruby in part because of how much NOT like Perl it is. Or perhaps I *already* know enough C. I spent part of a summer learning C, and the most important thing I learned was how much I disliked the decisions the language designers had made. > One of the great virtues of Ruby is the way it hooks into C code. > Suggesting that augmenting a Ruby program with a C-based library is > somehow un-Rubyish strikes me as, well, nearly nonsensical. "Un-Rubyish?" I don't believe I said any such thing. I was quite specific. Claiming you can make Ruby faster by not using it, is nonsensical. Claiming you can make a *program* written in Ruby by replacing some part of it with another language is perfectly reasonable. Confusing the two is sloppy reasoning. For the record, although it's irrelevant to my position, I agree that Ruby's ability to hook into C code is a strength of the language. > I don't think anyone said that Ruby itself was intrinsically slow for > every task, Let's see. What was that quote that started this thread? Oh, yes. "I�ll be honest right away though and say that Ruby is slow." Note the lack of qualifiers. Happily, most people (including, as stated earlier, myself) find Ruby's speed, however it might compare to alternatives, more than adequate. > so for most of the people concerned with speed (people whose concerns > tend to arise from professional or academic circumstances), suggesting > the use of C sounds more than a little reasonable. It's pragmatic and > professional. I quite agree. Nor have I disagreed with this in any way. I will point out, superfluously I hope, that the merits of extending Ruby's abilities, whether for speed or for some other reason, are quite unrelated to my precis, as summarized in the subject line.