Getting Ruby approved

[Joe Van Dyk]

Hi,

I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.

I was asked this question: "The question is, is Ruby bringing
something extra to the table, that we can't do with Perl, Python, Tcl,
Guile? E.g., are there OSS packages that we want to use which need
Ruby?"

I mentioned Rails and DRb as being the most useful applications of
Ruby to me. But can someone help me out with more?

Thanks,
Joe Van Dyk

 

[Hal Fulton]

Hi,

I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.

I was asked this question: "The question is, is Ruby bringing
something extra to the table, that we can't do with Perl, Python, Tcl,
Guile? E.g., are there OSS packages that we want to use which need
Ruby?"

I mentioned Rails and DRb as being the most useful applications of
Ruby to me. But can someone help me out with more?

On the one hand, all Turing-complete languages are equivalent.

In a more practical vein, sometimes there are libraries/packages
with which you need to interface, making some language a more
natural choice than others.

Neither of these points sells Ruby. What sells Ruby is the
productivity that programmers have when they use it.

This is only my opinion: I don't consider Perl as being on a level
with Ruby in this respect, and Tcl is not even close. Python, I
think, is very similar to Ruby in terms of productivity. I am not
familiar with Guile.

In case it helps any, you can refer to my article on devsource.com --
it was written partly to sell the idea that Ruby is now mainstream.


Hal

 

[Pat Maddox]

Show them the 10x productivity claims If you find anything that
shows that you can increase productivity by three-fold, you'll have no
trouble selling it to them.

 

[Bill Guindon]

On the one hand, all Turing-complete languages are equivalent.

In a more practical vein, sometimes there are libraries/packages
with which you need to interface, making some language a more
natural choice than others.

Neither of these points sells Ruby. What sells Ruby is the
productivity that programmers have when they use it.

This is only my opinion: I don't consider Perl as being on a level
with Ruby in this respect, and Tcl is not even close. Python, I
think, is very similar to Ruby in terms of productivity. I am not
familiar with Guile.

In case it helps any, you can refer to my article on devsource.com --
it was written partly to sell the idea that Ruby is now mainstream.

To save you the search:
http://www.devsource.com/article2/0,1759,1778695,00.asp

I'll 2nd Hal's comment, it's the ease of use, and more importantly
"readability" that sold me. Having done quite a bit of perl in the
past, I love Ruby's clean look and the fact that I can read code that
I haven't looked at for a month or more (especially since I only use
it occassionally).

 

[Robert Klemme]

Hi,

I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.

I was asked this question: "The question is, is Ruby bringing
something extra to the table, that we can't do with Perl, Python, Tcl,
Guile? E.g., are there OSS packages that we want to use which need
Ruby?"

I mentioned Rails and DRb as being the most useful applications of
Ruby to me. But can someone help me out with more?

Not exactly a package... But reuse is more likely with Ruby than with
Perl simply because in a year from now you'll be still able to read and
understand the code you write today quickly.

Kind regards

robert

 

[Joao Pedrosa]

Hi,

Hi,

I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.

I was asked this question: "The question is, is Ruby bringing
something extra to the table, that we can't do with Perl, Python, Tcl,
Guile? E.g., are there OSS packages that we want to use which need
Ruby?"

I mentioned Rails and DRb as being the most useful applications of
Ruby to me. But can someone help me out with more?

Ruby has closures, better low level support (Ruby/C), better OO
support, better core developers and better community, along with the
better libraries and overall language. Tell them that they can
dump all the other languages and use only Ruby.

Cheers,
Joao

 

[Adriano Ferreira]

Ruby has closures, better low level support (Ruby/C), better OO
support, better core developers and better community, along with the
better libraries and overall language. Tell them that they can
dump all the other languages and use only Ruby.

And you have forgotten about bf or even better Intercal. They are
funnier, more useless, but lays less claims than you did above.

Regards,
Adriano.

P.S. "Thou shall not be arrogant", unless thou want people very far from you.

 

[Adriano Ferreira]

Ruby has closures, better low level support (Ruby/C), better OO
support, better core developers and better community, along with the
better libraries and overall language. Tell them that they can
dump all the other languages and use only Ruby.

Sorry for being ironic at first. But it would be better to rephrase
as: "Tell them to give Ruby a try and soon they can dump all the other
languages."

Adriano.

 

[tony summerfelt]

Neither of these points sells Ruby. What sells Ruby is the
productivity that programmers have when they use it.

This is only my opinion: I don't consider Perl as being on a level
with Ruby in this respect, and Tcl is not even close.

interesting. i see a lot of messages here along the lines of 'which
gui kit should i use with ruby'...and then everyone pipes up with
their favorite...

of course by then in tcl/tk land, we've already finished coding up our
interfaces

i had a client tender for a very specific one-time utility. they asked
in house c++ and java programmers, and externally my name came up
because of the local perl work i've done...

when i read the specs for the program they wanted i told them they
could have it in an hour if they didn't care about which language it
was (they were expecting perl from me at that point).

i used tcl/tk...the interface, which needed a certain arraignment of
widgets, took maybe 5 minutes to code up (a RAD tool at this point
would have slowed me down). the rest of the code was trivial.

so the language that was 'not even close' brought me over $1000 in
less than an hour. tcl/tk really is a sleeper language. i'm amazed
that it's not more popular than it is outside of comp.lang.tcl

i'm still deciding on a permanent gui api for ruby
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

 

[Lyle Johnson]

I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.

I was asked this question: "The question is, is Ruby bringing
something extra to the table, that we can't do with Perl, Python, Tcl,
Guile? E.g., are there OSS packages that we want to use which need
Ruby?"

I mentioned Rails and DRb as being the most useful applications of
Ruby to me. But can someone help me out with more?

Though it's not a direct answer to your question, I tend to agree with
some of the other replies that if you try to "sell" Ruby to your
co-workers (or the higher-ups) by comparing it to other languages'
features and applications, you're fighting a losing battle. I for one
would love to be there when you try to explain to your boss that
Boeing should adopt Ruby because it has closures.

Having said that, if you haven't seen it already, you might want to
take a look at Andy Hunt's presentation on "Ruby Insurgency"
(presented at the first Ruby Conference back in 2001):

http://www.pragmaticprogrammer.com/talks/Ruby/RubyInsurgency.pps.zip

This is sort-of the approach that I'm using here at work (where most
of our development work is done in Java), in an attempt to introduce
people to Ruby. I use Ruby for a lot of little maintenance tasks
involved in building our code, and when someone asks "How did you do
that?" or, "Can I get a copy of that program?", it gives me an
opportunity to tell them a little bit about Ruby.

Hope this helps,

Lyle

 

[Booker C. Bense]

-----BEGIN PGP SIGNED MESSAGE-----

Hi,

I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.

I was asked this question: "The question is, is Ruby bringing
something extra to the table, that we can't do with Perl, Python, Tcl,
Guile? E.g., are there OSS packages that we want to use which need
Ruby?"

I mentioned Rails and DRb as being the most useful applications of
Ruby to me. But can someone help me out with more?

_ For me the biggest productivity gain between ruby and perl is
when you need to write modules to interface with existing
libraries. This is about a 1000 times simpler in Ruby than perl.

_ Booker C. Bense


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBQk1syWTWTAjn5N/lAQFnLgQAlVxcU1dpCxmZutprfjJHiyEihYicaqYd
3BED8cPmw1Dxv5Kn34CYpHDkjueqp6YeLnNd6Pt+0TcHa7JAY//osqrWwnV/SioE
tGDTJWfGLSyJ5hmAHym8/Dxy819xJ96VrwvdKqEovThvq9e0Pd+Ay0l95Z2J406q
4UIHSnUzDkU=
=vuCT
-----END PGP SIGNATURE-----

 

[Phlip]

Though it's not a direct answer to your question, I tend to agree with
some of the other replies that if you try to "sell" Ruby to your
co-workers (or the higher-ups) by comparing it to other languages'
features and applications, you're fighting a losing battle. I for one
would love to be there when you try to explain to your boss that
Boeing should adopt Ruby because it has closures.

Boss; "So does Perl!"

 

[Lyle Johnson]

_ For me the biggest productivity gain between ruby and perl is
when you need to write modules to interface with existing
libraries. This is about a 1000 times simpler in Ruby than perl.

Combine this with the 10x productivity gain you'd get by throwing
Rails into the mix, and that boosts one person's productivity up to a
staggering 10,000x. With that kind of horsepower you'd only have to
work, what, one day every 27 years or so?

 

[Jim Freeze]

I'm trying to get Ruby added to one of the "supported" OSS tools at Boeing.

I was asked this question: "The question is, is Ruby bringing
something extra to the table, that we can't do with Perl, Python, Tcl,
Guile? E.g., are there OSS packages that we want to use which need
Ruby?"

Having introduced Ruby at a company and having been successful in
having it replace Perl, I can tell you that the process may take
some time. Most of the comments in this thread have been right on.
As mentioned earlier, Andy's Insurgency talk gives good advice about
how to procede as an individual, but eventually, you need 'mind share'.

The 'mind share' can come in several ways.
1) From a boss who mandates Ruby.
2) From a group of respected developers who prefer to use Ruby.
3) From a kick-but application (or two) that is written in Ruby
(accompanied with a pleased manager).
4) From a good app that is written in near zero time
(also accompanied with a pleased manager).

#1 can be affective for moving a political agenda forward, but it
doesn't do anything for internal committment from developers.
#2 takes time, but is where you eventually want to go. #3 and #4
can be done by yourself.

It was interesting to see, in the beginning, that I got some of
the same questions, "How does Ruby differ from Perl", or
"What does Ruby offer that Perl doesn't?". Now, the questions
are reversed. For the occasional person that doesn't use Ruby,
he is bombarded with "Why didn't you use Ruby for that project?"

My main approach to management was on concepts. These concepts,
interestingly, have not changed over time:

1. Scalable
2. Readable/Maintainable
3. Reusable

I would suggest some seminars where you demonstrate/teach Ruby,
and include a segment on these items as motivators for Ruby.
And I often tell people, yes, there are thousands of languages
out there that one could use, and I would suggest that one always
use the best language for the job. It just so happens, that for
the kind of work that we do, Ruby is the best language. This will
bear itself out over the course of time. In addition, Ruby plays
very nicely in a corporate environment.

Of course, it doesn't hurt to have a sense of humor. When I went
before the VP to present an abstract on a Ruby course I developed,
I got the question, "What is Ruby?". I knew that a technical description
would be lost. So I had to use something he was familar with.
So, my reply was, "It is a fully object-oriented scripting language.
Some describe it as Perl's prettier, younger sister." That got a good
chuckle. And, it didnt' hurt that the abstract had almost every
conceivable topic for what we use scripting languages for.
It was readily approved, and after several people had taken the
course and began using the language, many of the old Perl die hards
came to me in private and declared that they were never going to
program in Perl again. You can't buy or mandate that kind of allegiance.

 

[Joe Van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----



_ For me the biggest productivity gain between ruby and perl is
when you need to write modules to interface with existing
libraries. This is about a 1000 times simpler in Ruby than perl.

I've not written C modules in Perl or Python. How does Ruby compare
to them in that respect?

 

[Phil Tomson]

interesting. i see a lot of messages here along the lines of 'which
gui kit should i use with ruby'...and then everyone pipes up with
their favorite...

of course by then in tcl/tk land, we've already finished coding up our
interfaces

i had a client tender for a very specific one-time utility. they asked
in house c++ and java programmers, and externally my name came up
because of the local perl work i've done...

when i read the specs for the program they wanted i told them they
could have it in an hour if they didn't care about which language it
was (they were expecting perl from me at that point).

i used tcl/tk...the interface, which needed a certain arraignment of
widgets, took maybe 5 minutes to code up (a RAD tool at this point
would have slowed me down). the rest of the code was trivial.

so the language that was 'not even close' brought me over $1000 in
less than an hour. tcl/tk really is a sleeper language.

It's been sleeping for quite a while, don't wake it up ;-)

Atually, I know that EDA companies use Tcl/Tk for many of their GUI
needs. We're talking about software that sells for up to $200,000/seat
in some cases. It's still pretty widely used in EDA because Ousterhout
initially developed it for use with chip layout software.

i'm amazed
that it's not more popular than it is outside of comp.lang.tcl

But would you really want to do soemthing substantial in Tcl?


Phil

 

[leon breedt]

I've not written C modules in Perl or Python. How does Ruby compare
to them in that respect?

Perl's XS is arcane, inconsistent and easy to cause segfaults in.
You're never quite sure when you should or should not reference
something in Perl, for example. They've invented concepts for the
hacks you have to do to work around the crap architecture of the
system. Its far too low-level. Extension documentation is all over the
place, in disparate man pages, and requires reading of *all* of them
and understanding *all* of them to get something to build and run
reliably. Ruby is infinitely better than Perl in this regard.

I haven't much experience with Python extensions, although, Pyrex
looks like it makes Python extensions quite painless.

Leon

 

[gga]

Depends on what you compare against.

Against the basic C apis of the languages...

Compared to Perl: no point of comparison. Perl uses a pseudo C
language wrapper called XS that is plain and simply a nightmare to
learn, code for and maintain.

Compared to Python: very similar to ruby, but I prefer ruby. The ruby
api is much simpler as there is no need for reference counting (albeit
marking your own classes for the GC is also kind of a big pain in
ruby). The ruby macros used are also a tad shorter and probably a tad
easier to learn and memorize than all the Py* methods. Python,
however, is infinitely better if you ever need to wrap a library that
uses multiple inheritance, as the lack of MI in ruby may prove to be
too much of a headache in that case.


Against SWIG...
Perl is the most mature SWIG api, albeit SWIG's python support has more
or less now become the predominant implementation. SWIG's ruby is
still rather new and still has a couple of gotchas here and there
(mainly with C++ and overloaded functions, for example). That being
said, the fact that SWIG's ruby can throw away all the shadow classes
that are needed to have stuff be swigged in those other languages makes
it a) much nicer, and b) potentially faster in the future than other
SWIGs.
Ruby SWIG is also trying hard to support multiple inheritance thru
modules, albeit the feature is still in development.


Against Boost Python:
Ruby has nothing equivalent. I consider this a good thing. Boost
Python is a good idea, but it just pushes the limit of what C++
compilers can handle with templates and this, imo, currently leads to
both inefficient and hard to maintain/debug code.


Against Pyrex:
Ruby has nothing equivalent. Pyrex is somewhat akin to a slightly more
high-level version of ruby's DL module, but nowhere near as good as
SWIG. Still not clear to me why would you use it at all, other than
you prefer the cleaner python syntax wrapping to writing pseudo C files
as you do with swig.

 

[Phlip]

Perl's XS is arcane, inconsistent and easy to cause segfaults in.
You're never quite sure when you should or should not reference
something in Perl, for example. They've invented concepts for the
hacks you have to do to work around the crap architecture of the
system. Its far too low-level. Extension documentation is all over the
place, in disparate man pages, and requires reading of *all* of them
and understanding *all* of them to get something to build and run
reliably. Ruby is infinitely better than Perl in this regard.

I haven't much experience with Python extensions, although, Pyrex
looks like it makes Python extensions quite painless.

I have extended Python. It's about mid-way between Perl and Ruby. The
extension libs, such as Boost's C++ Python wrapper, make it relatively
painless.

Ruby just _starts_ in the painless zone, despite using pure C.

Click here:

http://www.c2.com/cgi/wiki?BroadbandFeedback

That shows a Wiki written in Ruby hosting test cases written in XML
containing Ruby sample code. The tester pushes the code into a C++ Qt
application built to respond to a suite of Ruby commands to draw fractals.
(Without the tests, you can write the Ruby directly into the Qt interface.)

The tester takes screenshots of Qt's OpenGL widget rendering the fractals,
and the Wiki renders these.

All of that works with tiny snips of _exemplary_ Ruby and C bonding, without
any excessive adapter layer.

 

[Mark Roseman]

But would you really want to do soemthing substantial in Tcl?

Phil,

I can tell you that for a lot of people the answer has been and
continues to be "yes", they would want to do something substantial
in Tcl. And yes, they have been quite successful at it.

Effective evangelism of Ruby would be better served if it was not
about implying that people who choose other tools are crazy or
misguided (or just missing out) but about trumpeting the great
things that Ruby has going for it, while at the same time
acknowledging it's still got its rough spots.

FYI, there are a lot of things in language like Tcl (and others)
that Ruby could learn from and benefit from; because its been
around substantially longer, its reached a level of maturity in
many areas that provides real benefits to developers. That's not
to slag Ruby, but just to suggest its not perfect (yet). But
knowing where other tools might be better today can only help Ruby
tomorrow, and that is something that would be good for everyone.

Mark
(http://www.markroseman.com)

p.s. incidentally, I see many parallels in this community in
terms of energy, enthusiasm, attitudes, etc. with what the
Tcl/Tk community was like 10-15 years ago, when it was first
emerging. Ditto Python several years back...