On Sep 30, 2005, at 12:01 PM, bonefry wrote:

>>> Unfortunatelly, without a faster VM, we won't have those  
>>> libraries too
>>> soon. Because if they are done in pure Ruby they might get too slow,
>>>
>>
>> You are totally using guesswork here and it's poorly researched guess
>> work at that.
>>
>
> No, I am using experience from PHP who has the same problem. Google  
> for
> NuSOAP and why it's not everyone's favorite choice ;)

Ruby has a SOAP library in its standard library and I've never seen a  
single complaint about its speed.  That would seem to imply more  
differences than similarities.

I guess I just don't feel you are giving us solid examples of Ruby  
being "too slow"?  Yes, our VM isn't the fastest.  We're working to  
correct that very thing, but in the meantime you seem to be implying  
that it is crippling the language and that's just not the case.

Ruby is like most other programming languages, find the right  
algorithm and it's fast enough.

> Also, pure Ruby libraries, should be easier to install on a server,  
> or am I wrong ?

Sure.  I would prefer to have everything I can in pure Ruby and most  
of the time that seems very reasonable.  When it's not, we can haul  
out C.

>>> And Ruby currently chokes on O(n).
>>>
>>
>> Oh please!  That's not even intelligent enough to provoke a comment.
>> Now you are simply ignoring reality.
>>
>
> Err, although I may have exagerated a little, when was the last time
> you did more than linear alghorithms in Ruby ?

I'm sure it hasn't been too long.  I don't even start thinking about  
something like that until the software turns up to slow.  If I code  
something up, and it works on the data I need to process in the time  
I need it done, who cares how much extra processing it's doing?  Not  
all data sets have millions of members.

James Edward Gray II