On Tue, Oct 01, 2002 at 10:19:51PM +0900, William Djaja Tjokroaminata wrote:
> Hi Alan,
> 
> I totally agree with the statement below; I think so far Ruby results in
> a very high human productivity.  Now the question is, in essence, do you
> want an option to reduce the productivity by 20%, if you can increase the
> computer productivity by 500%?  (This is even an option; you may choose to
> do it or stay with you current productivity level.)
> 
> Regards,
> 
> Bill
> ==========================================================================
> Alan Chen <alan / digikata.com> wrote:
> > Ultimately, I think it's this focus on the human factor is what drives
> > my productivity higher with Ruby.

Personally, I'm not interested in that tradeoff. If I want higher
performance, I can perform design/algorithmic optimizations best in
Ruby. If that doesn't suffice, I can drop into C/C++ or ASM or any
number of other well established, widely supported
languages. Furthermore, in that alternate language, I can focus on a
narrow optimization issue.

Now if you can keep the human productivity the same while increasing
run speed I'd be very interested (not to mention that more of the ruby
community would be more supportive).  So many of the recent syntax
extension discussions have assumed that Ruby as it is now would be
difficult to optimize because of the dynamic language features, but
that seems like a poorly examined supposition to me.  I would bet that
run-time dynamic updates in ruby code happens in a small set of
instances - and then primarily near startup.  There's no reason that a
optimizing, ruby, run-time engine couldn't go ahead and emit optimized
code with any number of type-based restrictions, but detect dynamic
updates which may invalidate that particular optimized code
block. Think of it as a ruby version of a Java HotSpot compiler.

- alan

-- 
Alan Chen
Digikata LLC
http://digikata.com