Fighting Ruby's bad fame

[gabriele renzi]

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]

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]

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.

 

[Jim Bob]

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.

 

[Lothar Scholz]

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]

hi lothar,

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

 

[gabriele renzi]

il Sat, 17 Jan 2004 03:17:17 +0900, Lothar Scholz

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]

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]

il Sat, 17 Jan 2004 03:17:17 +0900, Lothar Scholz


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

 

[Sam Roberts]

Quoteing (e-mail address removed), on Sat, Jan 17, 2004 at 05:38:27AM +0900:

Quoting gabriele renzi <[email protected]>:
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.

Doesn't ruby/cocoa "bind" to Aqua? Or at least use the same obj-c apis
that Aqua apps are using?

Sam

 

[Enrique Meza]

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.

 

[Lothar Scholz]

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.

 

[Bermejo, Rodrigo]

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]

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 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]

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

 

[gabriele renzi]

il Sat, 17 Jan 2004 05:38:27 +0900, jason r tibbetts

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]

Well, you need apps. We don't have applications. If you look at RAA or
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]

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?

 

[Dave Brown]

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

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.

If you try to design a programming language for programmers who
aren't very smart, only programmers who aren't very smart will
want to use it.

--Dave

 

[GGarramuno]

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.