OK, you trolled me :)

First, please let me apologize for the many errors and
inconsistencies 
in my post.  It may be that many of the things I am
going on about 
are actually fixed/about to be fixed/not really
broken, in which case 
I would be ever so glad to have my error pointed out
to me.  Also let me 
apologise for not knowing who Andy Roonie is.

<Zeppelin-packed rant about Perl (which I completely
agree with) snipped>

>Going back to Parrot, I place higher chances of Matz
finishing Rite
>(Ruby + VM) than I do of Parrot actually taking
flight.

But Parrot is a functioning, usable,
kinda-sorta-feature-complete
virtual machine whereas Rite is, well, imaginary. 
Perhaps I'll install it
on some imaginary servers.

>I've
>already moved on from the fame that was Perl and have
embraced my new
>mode of transportation.  Ruby's slick, fast, and
feels like driving a
>new BMW after years of a beat up, run down Mustang.  

>Ruby's not perfect mind you, but it has the elegant
design and
>ingenuity behind it that makes me believe that one of
these days,
>it'll get there.  What really excites me about Ruby
and its future is
>that it will do so elegance and with class. 
::shrug:: I don't know
>about you, but I think wings and a vertical take off
would be damn
>slick on a BMW, don't you?

I don't think the BMW analogy is terribly good.  I
would prefer the
following:  if Perl is like a Mustang, Ruby is like a
detailed plan of a
BMW.

I have been using (or trying to use) Ruby since Before
It Was
Famous (tm), and I have made countless attempts to
convince people
how great it is (which almost always succeed) and
countless attempts
to get it used in a real world project (never
succeeded yet).  The
conversations tend to go the same way each time.  In
order to explain
why I don't get the BMW analogy, please let me
summarize those conversations
in the form of a dialog between an Enthusiastic
Convert To Ruby, and a 
Wise, Prudent Software Engineer.


ECTR:  "Ruby has the power and scalability of an OO
language, the flexibility 
and elegance of a functional language, and the useful
text-munging abilities 
of Perl."
WPSE: "Okay, I believe you.  Let's use it for text
processing.  I guess there'll
be no problem with international data."
"Well, no.  As long as it's Japanese, and in EUC,
Shift-JIS, or UTF-8.  There's 
a single global variable in your program that you have
to set correctly before 
using a given string."
"The data is in UCS2, like Windows, Java, and COM use.
 The Solaris stuff is in
UCS4 because they just had to use wider characters
than NT.  Are you telling
me Ruby won't handle that?"
"Well, you'll need to compile in a special module. 
And you should bear in mind
that input from the console will be in Shift-JIS,
whatever your other strings
are like.  Ruby does not try and access the OS's
character conversion services,
so if a new encoding comes along you might have to
deal with it yourself."
"I... see.  Well, when this HAS been done, I take it
we can process the text
normally?  regexes work on wide characters, right?"
"Er, no.  There is some special code that makes most
operations work on 
the three encodings I mentioned, but otherwise it's
all a bit difficult.
Now that I think of it, even in those three encodings
you can't even get the 
character length of a string."
"Whereas length() in perl has returned the correct
answer since version 5.0."
"Yes.  Ruby can use UTF8 strings, like Perl, but the
assumption that a string is
an array of bytes is deeply embedded in the language."
"So... when you said 'text processing' you meat 'text
processing in exactly four
different possible encodings'.  Not 'text in general'.
 Not even 'Japanese 
and English text in general'.  Just EUC --"
"Actually, I should mention that in this case EUC is
only EUC-JP.  EUC-KR won't
work."
"I see.  I assume, by the way, that Ruby WILL be able
to process text -- 
meaning at least to use UCS2 or UTF8 internally -- in
the near future?"
"Well... it was scheduled for 2001, but there hasn't
been any information for a 
long time."
"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."
"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.  You
would have to install a package called RDB... and then
you would have to install
an appropriate database driver for it.  There's an
ODBC one that you can get a
binary of from some page in Japan, or if we have a
copy of gcc we can..."
"So there is no standard Windows distribution that
contains even such basics as
the ability to talk to a database?"
"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... 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."
"Well... the creator of Ruby has specifically
indicated that he isn't interested
in Windows support, but people are always making
noises about it..."
"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?"
"Okay, I guess we'll keep using Java for that sort of
thing, much as we loathe
it.  I assume that work is under way to create a
threadable, embeddable, 
flexible Ruby engine or VM?"
"Yes. At least, sort of.  There has never really been
any information
about it.  The last comment from the Creator was 'I
can promise nothing'."
"And the Windows distribution?"
"Again, it's hard to say either when or if."
"And the text processing?  The basic fundamental
ability to handle a string 
without someone having to remove all the difficult
bits first?"
"Again, there's not really any hard information."
"Okay.  Well, I think I've decided on a Ruby strategy,
based on the principles
of Pragmatic Management.  Let me run it by you.  Tell
me what you think."
"Okay."
"First, get the hell out of my office.  Second, hire
another Perl programmer, 
it's a skill that's going to last forever."

Thank you for reading this far.  I know that other
people's experiences may 
vary, and that some sites may be able to assume that
all text is ASCII or
that all windows installations can be personally
looked after.  However, these
three issues (text, Windows, threading), of which the
most important by far is
the text issue, have basically prevented Ruby from
being used at any site I have
worked at. Including sites in Japan. Even though there
were many people who
liked it and wanted to use it.

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. 


I would like to make it clear that I am not
complaining nor demanding these
features.  I just think that many in the Ruby
community do not realise how 
far Ruby is from being as useable as Perl, both in
terms of functionality 
and in terms of confidence-inspiring,
management-appeasing information about 
what's going on.

  Benjamin Peterson



x