On 6/13/05, Lothar Scholz <mailinglists / scriptolutions.com> wrote:
> Hello Michael,
>> On 6/12/05, Alexandru Popescu <the_mindstorm / evolva.ro> wrote:
>>> Also, I agree with the fact the optimization comes later in the
>>> dev cycles. But we need to have the doors open to optimize.
>>> Moreover, I read that in Ruby you can always go and code the hot
>>> spots in C. What if you don't have these resources? Which are
>>> the costs to bring such a resource and make him productive?
>> How does this issue relate to *ruby*? The same charge could be
>> levied at python, even J2EE. "What happens if you don't have the
>> resources to speed up something slow?"
> If a language is a few times faster then the risk factor that this
> happens is just lower. This is a management descision.

Sometimes yes, sometimes no. More often than I would like, but less
often, I imagine, than you think.

> There are many things to keep in balance when you start a project.
> Development time is just one of them and often not that important.

Actually, in my experience -- both with cusomisable largeware (a
billing system for ISPs) and with consumer-oriented software --
development time is one of the top items of concern. Not *the* top,
but definitely a component in the top (which is usually support
costs, a combination of tech support time, QA time, and developer
time, the cost of each rising).

> This is a domain where Ruby is unfortunately not useable at the
> moment (missing a good GUI toolkit is the second reason). And i
> would like to see it possible to use it there too.

I'd argue that Ruby's speed is secondary to the lack of a good
cross-platform GUI kit. I, too, would like to see Ruby perform
faster than it does. But I don't think that satisfying the alioth
shootout is going to make that happen. The problem *is* known, and
the solutions are at hand. If moving slowly.

-austin
-- 
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca