Fighting Ruby's bad fame

ruby-talk
1

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 ?

2

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

···

On Fri, 2004-01-16 at 12:05, gabriele renzi wrote:

3

Hello gabriele,

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

[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?

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.

[misconception 3]
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?

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:mailinglists@scriptolutions.com

4

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 emeza@saisamx.com

5

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.

6

In article uh3g00hgtmc9f30hsm2jn17hvt1e4csf1t@4ax.com,

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

Phil

···

gabriele renzi surrender_it@remove.yahoo.it wrote:

7

gabriele renzi surrender_it@remove.yahoo.it wrote in message news:uh3g00hgtmc9f30hsm2jn17hvt1e4csf1t@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.

8

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

9

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.

···

On 2004-01-16, Lothar Scholz mailinglists@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.

10

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

···

On Sat, 17 Jan 2004, Lothar Scholz wrote:

11

I did not heard someone talking about this in a long time, what about
you?

Hmmm, it is not the amount but the quality of documentation.

hey found one! :wink:

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

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

···

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

12

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 —+

13

In article af53b0ba.0401171921.7cf9b9b7@posting.google.com,

gabriele renzi surrender_it@remove.yahoo.it wrote in message
news:uh3g00hgtmc9f30hsm2jn17hvt1e4csf1t@4ax.com…

do a lot of things in volume and I know with ruby this would bite me.

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

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

  2. 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?

  1. 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).

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

···

GGarramuno GGarramuno@aol.com wrote:

14

— slumos@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…

– Thomas Adam

···

=====
“The Linux Weekend Mechanic” – http://linuxgazette.net
“TAG Editor” – http://linuxgazette.net

“ 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

15

Hello Kirk,

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

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.

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.

···

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

16

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 ? :slight_smile:

···

il Sat, 17 Jan 2004 03:40:54 +0900, Kirk Haines khaines@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.

17

Quoting gabriele renzi surrender_it@rc1.vip.ukl.yahoo.com:

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

···

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

–
jason

:wq

This mail sent using ToadMail – Web based e-mail @ ToadNet

18

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

:wink:

/R

19

In article slrnc0gbhj.dsb.invalid@mojo.chicken.com,

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

···

Jim Bob invalid@invalid.com wrote:

On 2004-01-16, Lothar Scholz mailinglists@scriptolutions.com wrote:

20

Which libraries do you use?

Do you write your own extensions?

···

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.

–
Simon Strandgaard