Fighting Ruby's bad fame

gabriele renzi

unread,

Jan 16, 2004, 12:04:05 PM1/16/04

to

Hi gurus and nubys,
Yesterday I had an epiphany[1] that I want to share.
WARNING: these is lazy thinking

It seem that, from time to time issues about ruby grow up as Urban
Legends and spread everywhere as misconceptions.
In the past the ruby community faced some of this problems..

[misconception 1]
About one year ago there was long talking about missing libraries.
Look at [ruby-talk: 62344]. dblack said something really interesting
at that time:

I'm getting worried that we're settling into a culture where Ruby is
"that great language that doesn't have the equivalent of CPAN,"

It seem that we fought that misconception[2]. And we won.
That argument became less and less common heard on internet forums,
and in general discussions. Possibly because, ATM we have libraries
that we did not had 1 year ago, or because other reached a greater
maturity level[3].

[misconception 2]
The next problem that ppl pointed out when talking about ruby was
"oh, yes, cool, but so little documentation..".
It seem that we won even this, thanks to a general effort about it[4].
I did not heard someone talking about this in a long time, what about
you?

[misconception 3]
The newer misconception that I notice is that ruby is just good as a
"prototype language". I heard this many times, and it popped up in
this list too, sometimes.
Wait: ruby *is* a great prototype language, but not just that.

Many people see language features like open classes, non-constants
constants, lack of static typing etc.. as "enterprise issues".
"you can't write serious apps in ruby, but it's good to prototype.."

How do you fight this?

Well, you need apps. We don't have applications. If you look at RAA or
RubyForge you may see lots of frameworks, libraries, but little apps.

Could you name 5 applications written in ruby and known to
non-rubyists? Could you do the same with other languages?

I know there are many people that use ruby.
But I wonder: when I talk about ruby and someone asks me to name a
largely used ruby app, why I can't think of anything?

Possibly ruby actually *is* just good for prototyping ?

PS
BTW there are even real reasons like the thread-safety, efficiency,
not big windows support[5]

--

[1] you just need to drive a car alone for >200Km withouth even a car
stereo, to get and epiphany for yourself

[2] or is it misconcept?

[3] we still need more libs, don't we ? not more than any other
language community, anyway..

[4] the pickaxe, 1.8.1/rdoc+ri integration, ruby-doc.org, some nuby
tutorials, people documenting the std libs, articles on internet(and
real life) resources, single projects with great documentation like
ruby-gnome2.. thank you all

[5] what about that patch to have threads working fine on windows? Why
there is not a mod_ruby/eruby/apache one click installer ?

Tom Copeland

unread,

Jan 16, 2004, 12:14:36 PM1/16/04

to

On Fri, 2004-01-16 at 12:05, gabriele renzi wrote:
> Well, you need apps. We don't have applications. If you look at RAA or
> RubyForge you may see lots of frameworks, libraries, but little apps.

Yup, I've noticed that too... but I think that's starting to slowly
change. Witness, if you will:

http://tourneybot.rubyforge.org/
http://ruby-doom.rubyforge.org/
http://rubygo.rubyforge.org/

These applications could have been written in any language, but were
done in Ruby... because it's an excellent language for the job.

> Could you name 5 applications written in ruby and known to
> non-rubyists? Could you do the same with other languages?

Mailman and ViewCVS were written in Python... no reason why they
couldn't have been done in Ruby, but someone did them in Python first...

Yours,

Tom

Lothar Scholz

unread,

Jan 16, 2004, 1:17:17 PM1/16/04

to

Hello gabriele,

Friday, January 16, 2004, 6:05:05 PM, you wrote:

gr> [misconception 2]
gr> The next problem that ppl pointed out when talking about ruby was
gr> "oh, yes, cool, but so little documentation..".
gr> It seem that we won even this, thanks to a general effort about it[4].
gr> I did not heard someone talking about this in a long time, what about
gr> you?

Hmmm, it is not the amount but the quality of documentation. I still
find a lot of functions very bad explained. No exact mention what
exceptions are raised, what are the exact input values etc.
Look at the man pages for unix syscalls or MSDN to see how functions
must be documented.

gr> [misconception 3]
gr> Well, you need apps. We don't have applications. If you look at RAA or
gr> RubyForge you may see lots of frameworks, libraries, but little apps.
gr> Could you name 5 applications written in ruby and known to
gr> non-rubyists? Could you do the same with other languages?

The problem is not that there are not well known applications. It is
that there is no enterprise application and not even one larger ruby
application. I searched sometime to find one but without luck. All of
the apps could be written in one or two month. So they are no prove that
Ruby is productive for programming in the large and programming in
teams. I have no problems finding large applications in PHP, Python,
Perl, Smalltalk or even in TCL.

And yes there are real technical problems why i wouldn't use ruby for
larger applications. The common programming style of for example
adding functions to base classes like Array are a reason why i would
not recommend the language for large application programming.

--
Best regards,
Lothar mailto:mailin...@scriptolutions.com

Jim Bob

unread,

Jan 16, 2004, 1:32:20 PM1/16/04

to

On 2004-01-16, Lothar Scholz <mailin...@scriptolutions.com> wrote:
> I have no problems finding large applications in PHP, Python,
> Perl, Smalltalk or even in TCL.
>
> And yes there are real technical problems why i wouldn't use ruby for
> larger applications. The common programming style of for example
> adding functions to base classes like Array are a reason why i would
> not recommend the language for large application programming.
>

Would you say that any of the other languages you mentioned are more
appropriate than Ruby? Or were large applications written in them in
spite of them also not being really up to the task?

I ask because I have a hard time seeing at least PHP and Perl as being
better for large application development than Ruby. The others I either
don't have any knowledge of at all (TCL), or would not strike me as being
markedly better or worse suited to building a large app than Ruby
(Python and Smalltalk).

This is admittedly a very fuzzy, "off the cuff" sort of judgement on my
part, though. I don't see things like your example of adding methods to
Array as really important, though. You just make sure that everyone on
team is aware not to do that if that's something you want to avoid.
Someone who goes against that kind of ground rule will find ways to
sabotage any project in any language, period.

Kirk Haines

unread,

Jan 16, 2004, 1:40:54 PM1/16/04

to

On Sat, 17 Jan 2004, Lothar Scholz wrote:

> Hmmm, it is not the amount but the quality of documentation. I still
> find a lot of functions very bad explained. No exact mention what
> exceptions are raised, what are the exact input values etc.
> Look at the man pages for unix syscalls or MSDN to see how functions
> must be documented.

I have to agree here. The overall quality and quantity of documentation
for many things Ruby is less than what I was used to, coming to Ruby from
Perl (and C, and Java, and...). I think that some of this might be due to
language issues -- human language issues -- and that if I could read
Japanese I would find more abundant and more complete documentation, in
some cases. That certainly isn't a complete answer, though, as there are
many instances of widely used components that lack any sort of substantial
documentation.

> The problem is not that there are not well known applications. It is
> that there is no enterprise application and not even one larger ruby
> application. I searched sometime to find one but without luck. All of
> the apps could be written in one or two month. So they are no prove that
> Ruby is productive for programming in the large and programming in
> teams. I have no problems finding large applications in PHP, Python,
> Perl, Smalltalk or even in TCL.

All of those languages have been around in widespread usage for a lot
longer than Ruby. Give it time. A few years ago I wrote a very large ETL
system in Perl for my employer at the time. There was a reliable, fault
tolerant framework for collecting and moving arbitrary data/log files from
external locations, identifying when new data was available and retriving
it, verifying the integrity of the data, etc. This was coupled to an ETL
system that used and XML based language to describe the data sources, the
transformations to perform on them, and what to do with the resulting
transformed data. This XMl langauge was compiled by a Perl parser into
executable Perl to perform those operations. The system was decently
fast, and worked pretty well. It did some really cool things with Perl.
It took several months to write it, as the entire system was pretty large.

if I were to do it again, I'd do it in Ruby, and knowing Ruby as I do, I
would expect that the finished product would be more robust, smaller,
easier to debug, and though probably a bit slower in execution, not
overwhelmingly so.

> And yes there are real technical problems why i wouldn't use ruby for
> larger applications. The common programming style of for example
> adding functions to base classes like Array are a reason why i would
> not recommend the language for large application programming.

I don't see why this, in itself, is a deal breaker. If code is changing
the behavior of a base class without one's knowledge, that isn't good.
However, presumably, when writing code, one is aware of what the libraries
that one is using are doing. Now, in part, one has to rely on the library
author to have provided good documentation, but at least in theory, one
should know if a class that is being used goes and much with Array.

This is not quite analagous, but in Perl, one can override most of the
builtin functions in the language. I know. One of the tools in my Perl
warchest was a neat little module that I wrote which made this very, very
simple. I used it to wrap a lot of functions with an Exception hierarchy
that I created. Someone who used some of my code without really knowing
what it was doing could be very surprised by this, but in practice it
never was a problem.

Kirk Haines

Lothar Scholz

unread,

Jan 16, 2004, 2:13:40 PM1/16/04

to

Hello Kirk,

Friday, January 16, 2004, 7:40:54 PM, you wrote:

KH> This is not quite analagous, but in Perl, one can override most of the
KH> builtin functions in the language. I know. One of the tools in my Perl
KH> warchest was a neat little module that I wrote which made this very, very
KH> simple. I used it to wrap a lot of functions with an Exception hierarchy
KH> that I created. Someone who used some of my code without really knowing
KH> what it was doing could be very surprised by this, but in practice it
KH> never was a problem.

You can do this in most languages. I have really bad hacks for some
tasks in python too. But the problem is that this programming style is
explained in a lot of books (as a good use case for the open class
feature) and is also used in a quite some programs.

I don't think that the freedom you get with the syntax (and some
semantic) in ruby is really a plus for application development.
And i completely disagree with Matz that programming languages and natural
languages have something in common.

We need strict languages and redirect the programmers creativity to
the design phase not the implementation hacks.

Alexander Kellett

unread,

Jan 16, 2004, 3:06:50 PM1/16/04

to

hi lothar,

On Friday 16 January 2004 20:13, Lothar Scholz wrote:
> I don't think that the freedom you get with the syntax (and some
> semantic) in ruby is really a plus for application development.

but yet, it quite obviously is a plus.

if you are annoyed with the freedom you just
lack the ability to control your coding style.

> And i completely disagree with Matz that programming languages and natural
> languages have something in common.
>
> We need strict languages and redirect the programmers creativity to
> the design phase not the implementation hacks.

ruby is flexible enough to provide much more of this so called "strictness".

in any case. mostly the need for "strictness" is just a way of making up for a
lack of good api's, api documentation, and thorough system wide tests.

mvg,
Alex

--
From Sharp minds come... pointed heads.
-- Bryan Sparrowhawk

gabriele renzi

unread,

Jan 16, 2004, 3:25:13 PM1/16/04

to

il Sat, 17 Jan 2004 03:17:17 +0900, Lothar Scholz
<mailin...@scriptolutions.com> ha scritto::

>gr> I did not heard someone talking about this in a long time, what about
>gr> you?
>
>Hmmm, it is not the amount but the quality of documentation.

hey found one! ;)

BTW i think you're right. Good documentation is really important. But
I really think documentation is getting better.

>The problem is not that there are not well known applications. It is
>that there is no enterprise application and not even one larger ruby
>application.
>I searched sometime to find one but without luck. All of
>the apps could be written in one or two month. So they are no prove that
>Ruby is productive for programming in the large and programming in
>teams.

well, I think there are some, just too little.
I think many people wrote larger ruby apps, maybe not gigantic, but
large.
It seem there is even a company that has a pair of anterprise-level
product written in ruby. (look at the RealWorldRuby page in the
section dedicated to Web applications)

>I have no problems finding large applications in PHP, Python,
>Perl, Smalltalk or even in TCL.

I know that this happens. I wonder why. I can't believe php is much
'eneterprise-friendly' that ruby. And I don't think ruby offers more
rope to hang you than SmallTalk :)

>And yes there are real technical problems why i wouldn't use ruby for
>larger applications. The common programming style of for example
>adding functions to base classes like Array are a reason why i would
>not recommend the language for large application programming.

Wonderful how you met my expcetations :)
It seem there are lot of people that thinks like you.
But you can even do this in SmallTalk, IIRC, and ST has been around
for many years with really big apps, what's wrong with ruby ?

thanks for your answer

gabriele renzi

unread,

Jan 16, 2004, 3:32:42 PM1/16/04

to

il Sat, 17 Jan 2004 03:40:54 +0900, Kirk Haines <kha...@enigo.com> ha
scritto::

>> The common programming style of for example
>> adding functions to base classes like Array are a reason why i would
>> not recommend the language for large application programming.
>
>I don't see why this, in itself, is a deal breaker. If code is changing
>the behavior of a base class without one's knowledge, that isn't good.
>However, presumably, when writing code, one is aware of what the libraries
>that one is using are doing. Now, in part, one has to rely on the library
>author to have provided good documentation, but at least in theory, one
>should know if a class that is being used goes and much with Array.

please forgive me, I'm dumb.
What's wrong with adding features to base classes?
Possibly the problem is ovverriding methods, I suppose,
but you'll get a warning for that..

class String
def to_s
'yp'
end
end

tmp.rb:2: warning: method redefined; discarding old to_s

BTW if matz agrees on RCR 180 we can even see something like:

set_warn_func proc { |warning|
raise NotEnterpriseException.new if warning =~/method redefined/
}

cool is'nt it ? :)

jason r tibbetts

unread,

Jan 16, 2004, 3:38:27 PM1/16/04

to

Quoting gabriele renzi <surren...@rc1.vip.ukl.yahoo.com>:

> il Sat, 17 Jan 2004 03:17:17 +0900, Lothar Scholz
> <mailin...@scriptolutions.com> ha scritto::
>

> >And yes there are real technical problems why i wouldn't use ruby for
> >larger applications. The common programming style of for example
> >adding functions to base classes like Array are a reason why i would
> >not recommend the language for large application programming.
>
> Wonderful how you met my expcetations :)
> It seem there are lot of people that thinks like you.
> But you can even do this in SmallTalk, IIRC, and ST has been around
> for many years with really big apps, what's wrong with ruby ?

This is a good point. If Ruby had been better-known in Europe & the US in the
late 90s, when Smalltalk shops were emigrating to Java en masse, perhaps it
would have seen widespread use in the enterprise. A friend of mine, who was a
longtime Smalltalker before being forced to use Java, would love Ruby's
"everything's-an-object" philosophy. Hey, if IBM entrusted enormous financial
apps to a dynamic language like Smalltalk, then anything's possible.

As for wider adoption, I'd like to find a Ruby-to-GUI binding not just for Tk,
but for gtk, MFC, or (the holy grail) Aqua on OS X.

--
jason

:wq
___________________________________________________________
This mail sent using ToadMail -- Web based e-mail @ ToadNet

Enrique Meza

unread,

Jan 16, 2004, 3:51:27 PM1/16/04

to

> How do you fight this?
>
> Well, you need apps. We don't have applications. If you look at RAA or
> RubyForge you may see lots of frameworks, libraries, but little apps.
>

Well been beginner in Ruby ( and OOP too) , I wrote this point of sale
2 years ago and I obtained great acceptance between some small
retailers.

http://don-manolo.red-libre.org.

--
Enrique Meza <em...@saisamx.com>

Lothar Scholz

unread,

Jan 16, 2004, 4:11:15 PM1/16/04

to

Hello gabriele,

Friday, January 16, 2004, 9:35:05 PM, you wrote:

gr> please forgive me, I'm dumb.
gr> What's wrong with adding features to base classes?
gr> Possibly the problem is ovverriding methods, I suppose,
gr> but you'll get a warning for that..

It's simply the danger of a namespace clash. At least if short and
simple names are used as i have seen as a suggestion in a ruby book.

At least library developer should avoid this as hell.

Robert Feldt

unread,

Jan 16, 2004, 4:21:08 PM1/16/04

to

>>And yes there are real technical problems why i wouldn't use ruby for
>>larger applications. The common programming style of for example
>>adding functions to base classes like Array are a reason why i would
>>not recommend the language for large application programming.
>>
>>
>
>
>

Well you need to describe why you think so cause a lot of us don't agree.

And then there is Array.freeze

;)

/R

Bermejo, Rodrigo

unread,

Jan 16, 2004, 7:29:34 PM1/16/04

to

>
>
>I know there are many people that use ruby.
>But I wonder: when I talk about ruby and someone asks me to name a
>largely used ruby app, why I can't think of anything?
>
>

Think this way,

People who decide (mostly managers) which language use on large
app,
(usually made for middle/big size companies) are guys around
40/50 years old
which grown on the age of compiled languages .

For a large app, you need experienced programmers [ some
companies ask for 10 years of experience
on.. for example C ], hard to find for ruby.

Of one thing I'm sure rubyist are more focused on other
things than write
large app.......is like mmmm

I got it....(I love to use this one ...)

"Language shapes the way we think and determines what we
can think about."
-- Benjamin Lee Whorf

When programming ruby you become a philosopher and
philosophers
are not worried about writing large app.

class RubyProgrammer < Programmer
include philosophy
end

ronnie.

Phil Tomson

unread,

Jan 16, 2004, 11:16:49 PM1/16/04

to

In article <uh3g00hgtmc9f30hs...@4ax.com>,

gabriele renzi <surren...@remove.yahoo.it> wrote:
>Hi gurus and nubys,
>Yesterday I had an epiphany[1] that I want to share.
>WARNING: these is lazy thinking
>
>
>It seem that, from time to time issues about ruby grow up as Urban
>Legends and spread everywhere as misconceptions.
>In the past the ruby community faced some of this problems..
>

<snip>

>
>
>
>[misconception 3]
>The newer misconception that I notice is that ruby is just good as a
>"prototype language". I heard this many times, and it popped up in
>this list too, sometimes.
>Wait: ruby *is* a great prototype language, but not just that.
>
>Many people see language features like open classes, non-constants
>constants, lack of static typing etc.. as "enterprise issues".
>"you can't write serious apps in ruby, but it's good to prototype.."
>
>How do you fight this?
>
>Well, you need apps. We don't have applications. If you look at RAA or
>RubyForge you may see lots of frameworks, libraries, but little apps.
>
>Could you name 5 applications written in ruby and known to
>non-rubyists? Could you do the same with other languages?
>
>I know there are many people that use ruby.
>But I wonder: when I talk about ruby and someone asks me to name a
>largely used ruby app, why I can't think of anything?
>

There probably are lots of Ruby apps out there, but most of them are used
quietly inside companies. I recall Dave Thomas talk at OSCON last year
about a large application he wrote for a non-profit a while back. Sounded
like it was pretty substantial - 20K+ lines as I recall.

I know of some Ruby apps that are being written that will never make it
outside corporate walls. I also know of a potential Ruby app (still
in the deciding phases) that will (if approved) make it outside, but
nobody who uses it will realize it's a Ruby app... that's all I can say ;-)

Phil

Phil Tomson

unread,

Jan 16, 2004, 11:19:58 PM1/16/04

to

In article <slrnc0gbhj....@mojo.chicken.com>,

Jim Bob <inv...@invalid.com> wrote:
>On 2004-01-16, Lothar Scholz <mailin...@scriptolutions.com> wrote:
>> I have no problems finding large applications in PHP, Python,
>> Perl, Smalltalk or even in TCL.
>>
>> And yes there are real technical problems why i wouldn't use ruby for
>> larger applications. The common programming style of for example
>> adding functions to base classes like Array are a reason why i would
>> not recommend the language for large application programming.
>>
>
>Would you say that any of the other languages you mentioned are more
>appropriate than Ruby? Or were large applications written in them in
>spite of them also not being really up to the task?
>
>I ask because I have a hard time seeing at least PHP and Perl as being
>better for large application development than Ruby. The others I either
>don't have any knowledge of at all (TCL), or would not strike me as being
>markedly better or worse suited to building a large app than Ruby
>(Python and Smalltalk).

TCL/TK gets used a lot in the EDA (Electronic Design Automation) industry.
It's a postitively awful language, yet there are some fairly good sized
GUIs written with it.

If TCL can be used for such things, surely Ruby can be with great
improvements in productivity, OOness, even speed (TCL is very slow).

>
>This is admittedly a very fuzzy, "off the cuff" sort of judgement on my
>part, though. I don't see things like your example of adding methods to
>Array as really important, though. You just make sure that everyone on
>team is aware not to do that if that's something you want to avoid.
>Someone who goes against that kind of ground rule will find ways to
>sabotage any project in any language, period.

I don't see the problem either. If you find these features problematic,
just don't use them.

Phil

Thomas Adam

unread,

Jan 16, 2004, 11:58:27 PM1/16/04

to

--- Phil Tomson <pt...@aracnet.com> wrote:

> TCL/TK gets used a lot in the EDA (Electronic Design Automation)
> industry.
> It's a postitively awful language, yet there are some fairly good sized
> GUIs written with it.

Oh, what is wrong with it? Certainly, I think it is nice fast means of
generating a GUI. If you're that unhappy with it, try looking at the
bindings to fltk.

> If TCL can be used for such things, surely Ruby can be with great
> improvements in productivity, OOness, even speed (TCL is very slow).

It's only slow if you try writing an implementation of say "mozilla".

-- Thomas Adam

=====
"The Linux Weekend Mechanic" -- http://linuxgazette.net
"TAG Editor" -- http://linuxgazette.net

"<shrug> We'll just save up your sins, Thomas, and punish
you for all of them at once when you get better. The
experience will probably kill you. :)"

-- Benjamin A. Okopnik (Linux Gazette Technical Editor)

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html

gabriele renzi

unread,

Jan 17, 2004, 4:16:12 AM1/17/04

to

il Sat, 17 Jan 2004 05:38:27 +0900, jason r tibbetts
<tibb...@acm.org> ha scritto::

>
>As for wider adoption, I'd like to find a Ruby-to-GUI binding not just for Tk,
>but for gtk,

ruby-gnome2.sourceforge.jp, wonderful Gtk bindings
>MFC,
I suppose Swin/vruby is what you may like

> or (the holy grail) Aqua on OS X.

I think there are cocoa and carbon bindings. just not tried ;)

Kero

unread,

Jan 17, 2004, 5:43:37 AM1/17/04

to

>> Well, you need apps. We don't have applications. If you look at RAA or
>> RubyForge you may see lots of frameworks, libraries, but little apps.

My framework for computer vision at work (proprietary, can't share, sorry)
is done in such a way that the application is too small to be of any
interest (may be we are philosophers, may be we are just too experienced
to shove applications onto others, which are of no use to them as
programmer; doesn't this clash with the ruby-as-prototyping language point
of view? that's proto-apps, definitely, proto-libs, maybe...).

On a sidenote, I found one more advantage of programming in Ruby at work:
people will not abuse my research/experimenting code as real product code
(which tends to happen with C, C++ and Java). The reason: noone knows the
language, so they are certainly not going to learn it to put it in some
product. Even though some of my code has been running stable for months.

Btw: as long as I experience SEGFAULTS with Ruby, usually within
hours, Ruby is not ready for certain kinds of work. Ruby 1.8.1 seems to
have taken away my SEGFAULTS, but you'll have to do a bit more than that
to convince me Ruby is completely safe.

But, I gladly take these minor disadvantages with the major advantages
Ruby offers.

+--- Kero ----------------------- kero@chello@nl ---+
| all the meaningless and empty words I spoke |
| Promises -- The Cranberries |
+--- M38c --- http://httpd.chello.nl/k.vangelder ---+

Simon Strandgaard

unread,

Jan 17, 2004, 6:26:41 AM1/17/04

to

On Sat, 17 Jan 2004 10:43:37 +0000, Kero wrote:
> Btw: as long as I experience SEGFAULTS with Ruby, usually within
> hours, Ruby is not ready for certain kinds of work. Ruby 1.8.1 seems to
> have taken away my SEGFAULTS, but you'll have to do a bit more than that
> to convince me Ruby is completely safe.

Which libraries do you use?

Do you write your own extensions?

--
Simon Strandgaard

GGarramuno

unread,

Jan 17, 2004, 10:21:14 PM1/17/04

to

gabriele renzi <surren...@remove.yahoo.it> wrote in message news:<uh3g00hgtmc9f30hs...@4ax.com>...

>
> How do you fight this?
>

You don't. Every person and industry is different and ruby (or
whatever) may indeed not be the best choice. Working in the computer
graphics industry, I see ruby as a potential godsend for replacing
many of the current languages in use (fx houses and those doing cg
movies have done an evolution of using tcl, perl and now python and
sometimes this has led to all 3 of them being still in use in some
tools or applications, with java being used for some web stuff, and
c/c++ for large applications where speed matters).
I love ruby for its syntax, its clean code, its built-in regex, its
ease of building extensions, etc.
Yet, I still cannot completely and blindly suggest it over the other
tools in that industry as it is missing 4 or 5 things imho. But it is
damn close, if you ask me.

1) Speed.
This is still a critical factor. As an alternative to perl or python,
I need to match their speed or be better. Ruby currently isn't there
yet imho. I'm not sure if ruby's design of opening classes will
hamper it or not. Perhaps the solution will lie in allowing for a VM
and the possibility to use the language either "on-the fly" or with a
precompilation phase (most languages and OS architectures seem to be
evolving in that direction, too, which would then mean that only the
language's syntax may be of importance, then). For simple parsing web
pages or small things, speed is not an issue, but vfx houses tend to
do a lot of things in volume and I know with ruby this would bite me.

2) Localized modification of built-in classes.
While arguably a feature of ruby, the truth is that at a large scale
this leaves the door open to chaos. VFX is a dynamic industry. Oa
normal production, you have 10 to 50 technical directors, many of them
writing and updating scripts (and all of them with different amount of
programming knowledge), and usually doing so without a true
coordination. This is not chaos, but it is a true benefit for the
production and the facility. Lacking namespaces or so is an issue in
ruby and I know such an issue would not even arise for python, so this
is also a minus for the language.

3) Better english documentation.
There's still the need for good english docs of all the libraries that
are shipped with ruby. There's also the need for documenting what
constructs make ruby a tad faster or slower. There's also the need
for a solid "cookbook" a la perl or python, albeit some web docs are a
step in the right direction.

4) Better multiplatform support and libraries.
Ruby is still somewhat inmature in dealing with scripts that would be
run across multiple platforms. Determining the platform, OS and OS
version at runtime is still a pain in ruby compared to python or perl.
A library for this is neeed asap. Same for dealing with terminals.
If I keep having time, I'll try to adress this.

5) Better 3d math libraries.
Matrix.rb is really of no use. Yoshiyuki Kosano's math3d library is
much need step in the right direction, thou.

6) Better emacs support. Tools to do automatic refactoring.
The use of "end" as a delimiter makes it still hard in emacs to
determine to which block it corresponds, unlike a bracket. Some easy
macro is needed for that. In some way, ruby seems to suffer from this
a tad like python, which makes refactoring important to keep functions
within a page long. Thus, automatic refactoring tools would also be a
godsend (specially if they work with emacs and vi like the python
library refactoring does).

7) Multiple inheritance.
While this is something imo a scripting language can indeed do without
(and I kind of like that), it does present a big headache if you want
to integrate a C/C++ library that does depend on multiple inheritance.

Phil Tomson

unread,

Jan 18, 2004, 12:43:25 AM1/18/04

to

In article <af53b0ba.04011...@posting.google.com>,

GGarramuno <GGarr...@aol.com> wrote:
>gabriele renzi <surren...@remove.yahoo.it> wrote in message
>news:<uh3g00hgtmc9f30hs...@4ax.com>...
>

>do a lot of things in volume and I know with ruby this would bite me.
>
>2) Localized modification of built-in classes.
>While arguably a feature of ruby, the truth is that at a large scale
>this leaves the door open to chaos. VFX is a dynamic industry. Oa
>normal production, you have 10 to 50 technical directors, many of them
>writing and updating scripts (and all of them with different amount of
>programming knowledge), and usually doing so without a true
>coordination. This is not chaos, but it is a true benefit for the
>production and the facility. Lacking namespaces or so is an issue in
>ruby and I know such an issue would not even arise for python, so this
>is also a minus for the language.

can you elaborate? Ruby has namespaces defined by modules.

As far as modifying builtin classes goes, we're hearing a lot in
this thread about how this is a problem. Personally, I don't see it as
long as you're not redefining predefined methods.

However, if you really don't want anyone modifying built-in classes then
you can use freeze:

irb(main):001:0> Array.freeze
=> Array
irb(main):002:0> class Array
irb(main):003:1> def foo
irb(main):004:2> "foo"
irb(main):005:2> end
irb(main):006:1> end
TypeError: can't modify frozen class
from (irb):3

I suppose you could even define some sort of make_safe method that
iterates
through all of the built-in classes/modules (and even ones that you've
added) and calls freeze on them, thus
saving you from having to individually freeze each one - it wouldn't be
that hard to do.

In fact, here's the code for doing it:

def make_safe
ObjectSpace.each_object(){|o|
if(o.class == Class || o.class == Module)
o.freeze
end
}
end

call make_safe and all of the current Class and Method objects in
ObjectSpace are frozen. Maybe there should be an RCR for a commandline
argument that actually does this when Ruby is invoked.

However, I consider being able to (judiciously) add methods to built-in
classes one of the great features of the language and I really doubt that
when people are considering Ruby for a project that very many of them come
to the fact that classes are always open and decide that it's a deal breaker.
The kinds of 'dangerous' things you can do with Perl (for example) haven't
seemed to hinder it too much over the years.

>
>3) Better english documentation.
>There's still the need for good english docs of all the libraries that
>are shipped with ruby. There's also the need for documenting what
>constructs make ruby a tad faster or slower. There's also the need
>for a solid "cookbook" a la perl or python, albeit some web docs are a
>step in the right direction.
>
>4) Better multiplatform support and libraries.
>Ruby is still somewhat inmature in dealing with scripts that would be
>run across multiple platforms. Determining the platform, OS and OS
>version at runtime is still a pain in ruby compared to python or perl.
> A library for this is neeed asap.

Perhaps, but I've written lots of cross-platform scripts. How hard is it
to do:

case PLATFORM
when /win/
#do Windows things
when /nix/
#do Unix things
else
#whatever
end

?

How does Perl/Python handle this any easier?

>
>6) Better emacs support. Tools to do automatic refactoring.
>The use of "end" as a delimiter makes it still hard in emacs to
>determine to which block it corresponds, unlike a bracket.

This works in vim. I'm not an emacs user, but if they could get it
working with a vim script, I'm sure it can be done in emacs lisp.

>Some easy
>macro is needed for that. In some way, ruby seems to suffer from this
>a tad like python, which makes refactoring important to keep functions
>within a page long. Thus, automatic refactoring tools would also be a
>godsend (specially if they work with emacs and vi like the python
>library refactoring does).
>
>7) Multiple inheritance.
>While this is something imo a scripting language can indeed do without
>(and I kind of like that), it does present a big headache if you want
>to integrate a C/C++ library that does depend on multiple inheritance.

It's not so bad at this point. Swig 1.3.20 (for automatically
wrapping C++ code) handles this by considering each of the base classes as
modules that get mixed-in to the derived class.
For more details, see:

http://www.swig.org/Doc1.3/Ruby.html#n19

If you prefer not to use Swig, you could still borrow this idea. Swig
works quite well, however and it's a lot faster than 'hand' wrapping.

Phil

Mauricio Fernández

unread,

Jan 18, 2004, 3:25:45 AM1/18/04

to

On Sun, Jan 18, 2004 at 11:40:02AM +0900, Dave Brown wrote:
> : It's simply the danger of a namespace clash. At least if short and

> : simple names are used as i have seen as a suggestion in a ruby book.
> :
> : At least library developer should avoid this as hell.
>

> Smart developers know when this kind of thing is appropriate and
> when it isn't. Ruby is a language for smart people, and one of
> the facets of its design is letting the Ruby programmer make that
> judgement call.

"It's a language for smart wannabe (i.e people trying to be
smart)." - matz

;-)

--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Q: How does a Unix guru have sex?
A: unzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep
-- unknown source

GGarramuno

unread,

Jan 18, 2004, 9:02:40 PM1/18/04

to

>can you elaborate? Ruby has namespaces defined by modules.
>

Yes, but not good enough.
Compared to Perl or Python, include is missing the ability of Perl's use or
Python's import command to just bring only certain parts of the module into the
current namespace.
In perl, you can do:
use Module (:func1 :func2);
and in python:
from Module import :func1, :func2

And only those two functions/classes/variables get imported into the current
namespace. Ruby's include seems to be an all or nothing proposition,
unfortunately.

>As far as modifying builtin classes goes, we're hearing a lot in
>this thread about how this is a problem. Personally, I don't see it as
>long as you're not redefining predefined methods

Correct. I do see this as a benefit of ruby, too, but not without some form of
leash in the language to have the ability to keep the addition/modification
local or under the programmer's control.
I've been using ruby for about 1 week & 1/2 and already run into that. I
created String#expand_tabs() function in a module of mine only to find a
similar (but less efficient implementation) of that function in another popular
ruby library. Freezing the class is no use as I WANT to be able to do that for
my own class.
This to me already points out the huge issue of name clashes. In this case, it
is not biggie as both functions do the same, but... it already sent shivers
down my spine.
While you can do such things in perl or python, too; those things are usually
discouraged while in the ruby way, they are not. And as I mentioned before,
the include's of the other languages are better than ruby's as the coder can
load the modifications selectively, too.
Personally I like this phisolophy of ruby, but I NEED to have the ability to
easily keep changes to base classes local to my class or in an easy way to
revert them.
Otherwise, it IS a deal breaker.

>
>Perhaps, but I've written lots of cross-platform scripts. How hard is it
>to do:
>
> case PLATFORM
> when /win/
> #do Windows things
> when /nix/
> #do Unix things
> else
> #whatever
> end

Well, that's the issue isn't it? What is #whatever?
Quick! Can you tell me how do I get the terminal's screen size in all these
platforms: win32, dos, linux, HP, sun, irix, ming32, cygwin, osx, mac9?
You know? Great! Now, can you tell me how ruby defines PLATFORM on each OS,
as I don't have each of those machines handy?
Now, better yet, can you tell me how can I distinguish the OS name and version
in ruby, since PLATFORM does not tell me that?
Those are the things missing from libraries and having at least ONE library
where all possible alternatives are listed would be nice.
In the case of perl, this is handled more or less as bad as ruby, but there are
a bunch of libraries that have been tested along the years that have a huge
list of these possibilities for you to learn from.
In the case of python, PLATFORM is much more simplified, as os.name can be only
one of 'posix', 'nt', 'dos', 'os2', 'mac', 'ce' or 'riscos'. No surprises
there and no need for any regex'es. Nothing weird like "i386-win32".

>
>This works in vim. I'm not an emacs user, but if they could get it
>working with a vim script, I'm sure it can be done in emacs lisp.

Yes, I'll take a look at writting an emacs macro for this. But still,
refactoring tools would be much more useful.

>
>http://www.swig.org/Doc1.3/Ruby.html#n19
>

Yes, been playing with swig1.3. Like it a lot, but it is missing some needed
stuff for ruby.
For example, ALL #define constants are translated to ruby. Even those that are
invalid ruby constants like those starting with underscores (and there does not
seem to be a way to ignore those, as with methods).
There seems no way to have swig automatically expose protected methods, which
is quite needed.
There is no %rubycode available like the %pythoncode directive in python mode
to create additional .rb code files.
And I'm not sure mixin's really can deal with multiple inheritance 100%
properly. Sure, methods are easy. I am concerned more about dealing with
variables (both class and instance), thou, as from my quick glance at it,
modules seem to be somewhat limited in this aspect.

Phil Tomson

unread,

Jan 18, 2004, 10:36:38 PM1/18/04

to

In article <20040118210240...@mb-m22.aol.com>,

GGarramuno <ggarr...@aol.com> wrote:
>>can you elaborate? Ruby has namespaces defined by modules.
>>
>
>Yes, but not good enough.
>Compared to Perl or Python, include is missing the ability of Perl's use or
>Python's import command to just bring only certain parts of the module into the
>current namespace.
>In perl, you can do:
> use Module (:func1 :func2);

You can do this. Remembering back to my Perl days (a distant, fading
memory), I never did this. It was always just 'use Module'. (but that's
not to say that being able to limit which functions are brought in isn't
useful and often warrented).

>and in python:
> from Module import :func1, :func2
>
>And only those two functions/classes/variables get imported into the current
>namespace. Ruby's include seems to be an all or nothing proposition,
>unfortunately.

Perhaps this warrants an RCR. Right now, Matz is very open to RCR's
and he's asking for a lot of them to be submitted for Ruby 2.
http://rcrchive.net/

Perhaps there could be optional arguments to require and include so that
methods can be listed (as you show above):

require "foo", :func1, :func2

include Foo, :func1, :func2

It's probably possible to do something like this now, I'd have to play
with it a bit to see what I can come up with.

>
>>As far as modifying builtin classes goes, we're hearing a lot in
>>this thread about how this is a problem. Personally, I don't see it as
>>long as you're not redefining predefined methods
>
>Correct. I do see this as a benefit of ruby, too, but not without some form of
>leash in the language to have the ability to keep the addition/modification
>local or under the programmer's control.
>I've been using ruby for about 1 week & 1/2 and already run into that. I
>created String#expand_tabs() function in a module of mine only to find a
>similar (but less efficient implementation) of that function in another popular
>ruby library. Freezing the class is no use as I WANT to be able to do that for
>my own class.
>This to me already points out the huge issue of name clashes. In this case, it
>is not biggie as both functions do the same, but... it already sent shivers
>down my spine.
>While you can do such things in perl or python, too; those things are usually
>discouraged while in the ruby way, they are not. And as I mentioned before,
>the include's of the other languages are better than ruby's as the coder can
>load the modifications selectively, too.
>Personally I like this phisolophy of ruby, but I NEED to have the ability to
>easily keep changes to base classes local to my class or in an easy way to
>revert them.

This is kind of what David Black's Ruby behaviors does.
http://uweb.superlink.net/~dblack/ruby/behaviors/

>
>>
>>Perhaps, but I've written lots of cross-platform scripts. How hard is it
>>to do:
>>
>> case PLATFORM
>> when /win/
>> #do Windows things
>> when /nix/
>> #do Unix things
>> else
>> #whatever
>> end
>
>Well, that's the issue isn't it? What is #whatever?

Whatever is whatever else you think your script might run on. Practically
speaking, you mainly need to cover: Windows, MacOSX, Linux and *BSD.

>Now, better yet, can you tell me how can I distinguish the OS name and version
>in ruby, since PLATFORM does not tell me that?
>Those are the things missing from libraries and having at least ONE library
>where all possible alternatives are listed would be nice.
>In the case of perl, this is handled more or less as bad as ruby, but there are
>a bunch of libraries that have been tested along the years that have a huge
>list of these possibilities for you to learn from.
>In the case of python, PLATFORM is much more simplified, as os.name can be only
>one of 'posix', 'nt', 'dos', 'os2', 'mac', 'ce' or 'riscos'. No surprises
>there and no need for any regex'es. Nothing weird like "i386-win32".

But what if new OS's are developed? And how do I distinguish between OSX
and OS9 if all I get is 'mac'? Do they have an os.version as well?
Given that OS9 and OSX are such different beasts, I don't want them lumped
together.

PLATFORM is set at compile time in Ruby (as in compile time of the Ruby
sources). I suppose it would be nice if there were some way to actually
query the OS in such a way as to determine the OS name and version.
(perhaps another RCR is in order). How does Python setup the os
datastructure?

>
>>
>>This works in vim. I'm not an emacs user, but if they could get it
>>working with a vim script, I'm sure it can be done in emacs lisp.
>
>Yes, I'll take a look at writting an emacs macro for this. But still,
>refactoring tools would be much more useful.

Sure, but as you say Python and Perl don't have those sorts of tools
either. I guess this is one place where static typing make it easier for
the editor: it provides some idea about types of variables for
refactoring. But consider: Refactoring is already a lot easier in
dynamically typed languages like Ruby (or Python or Perl). The FreeRIDE
folks are planning some support for refactoring ASAIK.

>
>>
>>http://www.swig.org/Doc1.3/Ruby.html#n19
>>
>
>Yes, been playing with swig1.3. Like it a lot, but it is missing some needed
>stuff for ruby.
>For example, ALL #define constants are translated to ruby. Even those that are
>invalid ruby constants like those starting with underscores (and there does not
>seem to be a way to ignore those, as with methods).

I wonder how hard this would be to fix.

>There seems no way to have swig automatically expose protected methods, which
>is quite needed.
>There is no %rubycode available like the %pythoncode directive in python mode
>to create additional .rb code files.
>And I'm not sure mixin's really can deal with multiple inheritance 100%
>properly. Sure, methods are easy. I am concerned more about dealing with
>variables (both class and instance), thou, as from my quick glance at it,
>modules seem to be somewhat limited in this aspect.

Definately some limitations to this method of emulating MI. I'm not sure
these differences can ever be completely bridged. Ruby supports single
inheritance with mixins, whereas C++ supports multiple inheritance with
all of the associated problems that come with it. Swig makes a good
attempt to bridge the gap, but of course there will never be a perfect
bridge between the two.

Phil

slu...@yahoo.com

unread,

Jan 19, 2004, 1:56:24 AM1/19/04

to

I like to think I've done my small part for Ruby advocacy. About two
years ago I started using Ruby as a prototyping language, now it's my
group's main language. Last year we delivered 3 reasonably large Ruby
applications based on our research. We brought in a new developer
recently, and one of my co-workers told me "I gave mouse the Ruby book
and told him to go off and learn Ruby...well actually I told Ruby to
go teach itself to mouse." (we talk in usernames around here).

I was a big Perl guy, but now I haven't touched Perl in over a year.

(I just wanted to show where I'm coming from.)

When you install Perl, you get a completely unified and consistent
documentation system and a well-organized and consistent module system
and the ability to trivially install almost any module.

That's a really nice feature, and Ruby has nothing close. If you are
thinking about pointing to RDoc and raainstall, I'm sorry but you're
in denial. With Perl, if I suspect there is a module called
XML::Parser, I say something like "perl -MCPAN -e shell" and "install
XML::Parser". If I only suspect that Perl has an XML parser, I'm
likely to guess that it's called XML::Parser. If I want
documentation, I say "perldoc XML::Parser" and it finds the
documentation. If it can find the module, it can find the
documentation, and it looks basically the same across modules.

I should mention that I've never used raainstall, but even if that is
a solved problem, it doesn't handle the documentation problem. In my
experience, a random Ruby module may come with RDoc, or RD, or an HTML
file, or a README, or nothing. A lot of modules that use RDoc only
document methods, not philosophy / usage / examples.

I know that sounds like I'm criticizing, but really I'm not. I'm just
not good at writing diplomatically. I consider the above a minor
inconvenience at worst, although I am generally more likely to write
my own module before I try to figure out an existing one without good
documentation. I just don't think it's productive when some people
say Ruby documentation is "not good enough" or "not as good as Perl"
and the Ruby community simply declares the problem solved or a myth.

It's worth noting that if Perl has "better" documentation, it's
because the core Perl people purposely built a community where
non-conformism was punished. The transition from Perl 4 to Perl 5 was
marked by anyone asking for help with 4 being told that they should
use 5 instead, and anyone announcing a new program being told they
should rewrite it as a module instead. I don't know about anyone
else, but my impression of the Perl community at that time was not
certainly not that it was friendly.

Steve

Thomas Adam

unread,

Jan 19, 2004, 2:10:44 AM1/19/04

to

--- slu...@yahoo.com wrote:

[..snip..]

> It's worth noting that if Perl has "better" documentation, it's
> because the core Perl people purposely built a community where
> non-conformism was punished. The transition from Perl 4 to Perl 5 was
> marked by anyone asking for help with 4 being told that they should
> use 5 instead, and anyone announcing a new program being told they
> should rewrite it as a module instead. I don't know about anyone
> else, but my impression of the Perl community at that time was not
> certainly not that it was friendly.

You're comparing the two as if they're synonymous -- don't. Ruby is
evolving, yes. It has not been around nearly so long (ha!) as Perl. The
documentation is weak, but it is getting better. Miracles do not happen
overnight.

Why should we start adopting traits that Perl has? If we did that we might
as just well switch to perl at the end of the day...

Gavin Sinclair

unread,

Jan 19, 2004, 8:20:52 AM1/19/04

to

On Monday, January 19, 2004, 1:05:02 PM, GGarramuno wrote:

> I've been using ruby for about 1 week & 1/2 and already run into that. I
> created String#expand_tabs() function in a module of mine only to find a
> similar (but less efficient implementation) of that function in another popular
> ruby library.

Could you send me the efficient implementation? :)

> This to me already points out the huge issue of name clashes. In this case, it
> is not biggie as both functions do the same, but... it already sent shivers
> down my spine.

You DO test code before deploying it into a critical productiohn
system, don't you? What's so bad about name clashes? You find them,
fix them, and move on. Same as any other kind of coding error. And,
short of clashing with a library whose explicit purpose is to extend
the built-in classes, I bet you don't even find any name clashes. :)

> While you can do such things in perl or python, too; those things are usually
> discouraged while in the ruby way, they are not.

Not true. Some people like them, some don't. Good libraries take
care not to impinge on public namespaces unreasonably. Experimenting
with modified classes is quite encouraged in Ruby. Overdoing it is
not.

> And as I mentioned before, the include's of the other languages are
> better than ruby's as the coder can load the modifications
> selectively, too.

I don't like the sound of that "feature". A well-designed library
should be loaded in full. In OO languages especially, you either load
a class or you don't; you don't pick and choose methods.

Larger libraries may have several classes in a module, which can be
selectively loaded by loading different files (require "foo/a",
require "foo/b").

Selective importing of pure module functions *may* have some benefit,
but still sounds pretty average.

> Personally I like this phisolophy of ruby, but I NEED to have the ability to
> easily keep changes to base classes local to my class or in an easy way to
> revert them.

At the risk of re-igniting an old flamewar, no you don't. Not until
you prove that you need it anyway. At the moment it's mere paranoia.
No offense intended; we've all been there I'm sure.

I don't rule out the possibility of you proving that you need the
feature. And I think that namespaces/behaviours would be nice. You
have certainly hit on a controversial Ruby feature, and interesting
discussion on it is always ... well, interesting.

> Otherwise, it IS a deal breaker.

Take responsibility for your own code, and scrutinise third party code
you use. Run RDoc on them and see if any built-in classes appear.
Use Ruby to prototype a solution and then ask what's wrong with it.

Cheers,
Gavin

GGarramuno

unread,

Jan 19, 2004, 2:42:53 PM1/19/04

to

Gavin Sinclair <gsin...@soyabean.com.au> wrote in message news:<33606556942.2...@soyabean.com.au>...

> On Monday, January 19, 2004, 1:05:02 PM, GGarramuno wrote:
>
> > I've been using ruby for about 1 week & 1/2 and already run into that. I
> > created String#expand_tabs() function in a module of mine only to find a
> > similar (but less efficient implementation) of that function in another popular
> > ruby library.
>
> Could you send me the efficient implementation? :)
>

Sure, here it is. This implementation will perform a tiny bit slower
on short documents that are mainly separated by a single tab, but it
should perform dramatically faster in longer documents, specially
those with multiple contiguous tabs (last test, being the most
pathologial one). Of course, the best thing would be to move these
methods from ruby onto C, if you ask me:

require "benchmark"

class String

# Return new string with all tabs set to spaces
def new_expand_tabs(n=8)
n = n.to_int
raise ArgumentError, "n must be >= 0" if n < 0
return gsub(/\t/, '') if n == 0
return gsub(/\t/, ' ') if n == 1
h = self.dup
while h.gsub!(/^([^\t\n]*)(\t+)/) { |f|
val = ( n * $2.size - ($1.size % n) )
$1 << (' ' * val)
}
end
h
end

def old_expand_tabs(n=8)
n = n.to_int
raise ArgumentError, "n must be >= 0" if n < 0
return gsub(/\t/, "") if n == 0
return gsub(/\t/, " ") if n == 1
str = self.dup
while str =~ /\t/
str.gsub!(/(^.*?)\t/) { |s|
# Our match starts at the beginning of a line, so we count the
# characters before the tab, and expand the tab to the next multiple
# of N spaces.
width = $1.size
gap = n - (width % n)
# Replace the tab with 'gap' spaces.
$1 + (" " * gap)
}
end
str
end

end

### Dummy tests
n = 100000
s1 = "\t\t\t\t\t\tadssaa\t\t\t\t\t" * 1000
s2 = "\t\t\t\t\t\tadssaa\t\t\t\t\t\n\n\t\t\n" * n
s3 = "adssaa\t\t\t\t\t\nxxxxxxx\t\t\nyy\n" * n
s4 = "adssaa\t\t\t\t\txxxxxxx\n" * n
s5 = "\na\ta\t\a\ta\t\a\n" * n
s6 = "\na\tthis\t\is\ta\t\test\tof\thow\tgood\ttabulation\tis.\n" * n

t1 = ''
t3 = ''

Benchmark.bm { |x|
x.report("n ") { t3 = s2.new_expand_tabs(); }
x.report("o ") { t1 = s2.old_expand_tabs(); }
}

if ( t3 != t1 )
t3.gsub!(/\t/,'-')
t1.gsub!(/\t/,'-')
puts "new error!",t3,".",t1
end

Benchmark.bm { |x|
x.report("n ") { t3 = s3.new_expand_tabs(); }
x.report("o ") { t1 = s3.old_expand_tabs(); }
}