Andy Roonie is perhaps excessively optimistic

ruby-talk
1

OK, you trolled me :slight_smile:

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 ™, 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

2

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 :wink:

<… 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 :wink: 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.

3

> "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 :wink: 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.

Just to set the record strait, Apache 2 using the threaded MPM isn't
an issue of native threads, its an issue of multiple interpreters per
process. -sc

¡¡¡

--
Sean Chittenden

4

Lyle Johnson wrote:

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.

Ruby, then, has reached its Rubicon, http://www.ibiscom.com/caesar.htm
Will Matz be its Caesar and build a new Empire? Or will the important
issues noted by Benjamin be ignored? Full Unicode, threading, and a fast
VM are going to be critical factors.

¡¡¡

–
Clifford Heath

5

Hi,

¡¡¡

In message “Re: Andy Roonie is perhaps excessively optimistic” on 02/06/28, Clifford Heath cjh_nospam@managesoft.com writes:

Ruby, then, has reached its Rubicon, http://www.ibiscom.com/caesar.htm
Will Matz be its Caesar and build a new Empire? Or will the important
issues noted by Benjamin be ignored? Full Unicode, threading, and a fast
VM are going to be critical factors.

They will not be ignored. But ony History knows the future.

						matz.