Re: Andy Roonie is perhaps excessively optimistic

Benjamin Peterson wrote:


> to me.  Also let me 
> apologise for not knowing who Andy Roonie is.

Andy Rooney is a commentator who appears on "60 Minutes", a television
news magazine show in the U.S. His segment ("A few minutes with Andy
Rooney") appears at the end of every episode and is just a short
monologue about whatever's on Andy's mind that day. I don't think the
real Andy's done a rant on Perl 6 yet, though ;)

<... bits about i18n and text processing snipped ...>

I will take your word for it that these are significant roadblocks for
you and others. I typically deal with English (ASCII) text exclusively
and so it hasn't been an issue for me -- yet.

> "Right.  Well, I guess we'll carry on with Perl on the
> server, but maybe
> we can deploy Ruby on  the Windows desktops.  We could
> do with a powerful
>  scripting environment on those things.  Is there an
> ActiveState version?"
> "No.  ActiveState expressed interest in producing a
> Windows distribution quite
> a while back, but... well, it didn't happen.  There is
> a Windows binary 
> distribution, though."

Just curious, what would be the significance (benefit) of having an
ActiveState Windows distribution versus some other Windows distribution?

> "Good!  Let's just check if the database support works
> right, and then --"
> "Er, actually it's a distribution that doesn't have
> any database support.

The most recent Ruby installer for Windows (from Andy Hunt) included
Ruby/DBI, DBD/ODBC, DBD/Postgres, DBD/MySQL and DBD/Oracle.

> "There isn't really a 'standard' per se at all. 
> Actually there's a bit of a 
> split between native windows and cygwin, still."

I can compile Perl for the "native" Windows runtime or Cygwin, but the
standard installers for Perl (e.g. ActivePerl) are built for native Windows.

I can compile Python for the "native" Windows runtime or Cygwin, but the
standard installers for Python (e.g. the PythonLabs distro or
ActivePython) are built for native Windows.

I can compile Ruby for the "native" Windows runtime or Cygwin, but the
standard installer for Ruby (e.g. the Pragmatic Programmers' distro) is
built for native Windows.

Notice a pattern emerging?

> "I... see.  I assume, of course, that a standard
> Windows distro that puts a 
> predictable Ruby version with database support on a
> user's desk is coming up
> soon."

Based on previous point, I believe this is already available.

> "Well... the creator of Ruby has specifically
> indicated that he isn't interested
> in Windows support, but people are always making
> noises about it..."

This is an especially important point. Two of the primary reasons that
the Windows ports of Perl and Python have become so strong are that:

 1. There was a developer, or group of developers, who
    took up the task of making them strong. People like
    Mark Hammond (in the Python community) or ActiveState
    (in the Perl community).

 2. The lead developers (Guido and Larry) didn't resist
    Windows support.

So far, no one in the Ruby community has really emerged as a "leader"
for making the Windows port any stronger than it is. And it's not clear
that their suggestions or contributions would be incorporated into the
core anyways.

> "Right.  Well, heck, I guess we can carry on using
> Perl on the desktops too.
> I tell you what, though, we might still use Ruby for
> some large application that
> doesn't need to interact with the outside world much. 
> Ruby's clean OO structure
> should make multithreading pretty easy."
> "It doesn't do multithreading.  It has what you would
> call 'fibers', but they
> are not true threads.  If you perform a blocking
> operation, the whole program
> blocks.  The trouble is, the Ruby code assumes one
> Ruby machine per process so
> it's hard to roll your own multithreaded Ruby."
> "Well, how on earth do you use it in a web server,
> then?"
> "You remember Apache version one?"

Grins for the Apache 1 reference ;) Yes, I think most people agree that
Ruby needs native threads support. And I think it's equally clear that
there's no way to hack that into the present Ruby source and we'll need
to wait for Rite.

> This in itself, however, is not really a problem.  If
> Ruby isn't aimed at
> people who need internationalization, then so be it --
> it's free, after all.
> The problem is more the lack of information on when,
> if ever, things will
> change, which makes it difficult to reccommend Ruby
> with confidence.  It is 
> difficult to make Ruby seem like a good investment --
> or even 
> like a properly run software project -- when the main
> channel for information
> is the occasional laconic epigram from matz.
> 
> Questions like: 
> 'What is the status of Rite?'  
> 'When will we know what ruby's i18n support will
> consist of when it arrives?'  
> 'When will 1.8 be available and what will be in it?'
> 
> simply cannot be answered and as a result it is hard
> for Ruby to appear 
> credible outside of the lone developer's workstation.

Most of your questions point out Ruby's shortcomings for use as an
enterprise software development solution, i.e. a replacement for Java.
And for those points I'd have to agree with you. But obviously, people
are finding Ruby useful for other kinds of applications.

The last year or so have been an interesting period in Ruby's life. I
don't know how (or if) the development model should change, and of
course, it's ultimately Matz's decision. As with other languages, a lot
of Ruby's best functionality isn't implemented in the core, but rather
as extensions (e.g. database support), for which you don't need to
depend on Matz's schedule. But for things that do depend on
modifications to the core it would be nice to have some more concrete
plans to work with.