Re: Building a business case for Ruby

* Joe Van Dyk <[e-mail]> [2005-06-04 05:33:07 +0900]:

> I asked this question a little bit ago, but wanted to bring it back up.
> 
> I work for <insert huge company that makes really big expensive things
> here>.  We have "computing standards" that define what's allowable for
> usage internally and externally.  Technology evaluation boards, etc.
> 
> Here's an evaluation of Ruby:
> 
> "XXXX already has Product Standards for Python and Perl as
> Scripting/Dynamic languages. And for Java as a full programming
> language.
> 
> Ruby offer nothing significant not found in these XXXXX Standard
> languages, and an addition language just adds variation."

So, you're saying they are making judgements about Ruby without actually
even investigating it yet? ;)

> We've got mountains of unmaintainable perl stuff here, and I haven't
> really seen much in Python.  I'm in charge of developing some new
> software and would like to use Ruby.  Actually, the software is
> finished (very quickly) and I just need to get Ruby on the allowed
> list.  :(
 
> I don't need arguments about Perl vs Python vs Ruby.  I would like to
> see a discussion of:
> 
> 1)  Why one additional language isn't a bad thing
> 2)  Examples of existing Ruby usages in large scale applications
> 3)  How Ruby can benefit this place
 
This language stuff reminds me of religious conversion activities.
If you aren't the king and can't make declarations like: "Ala or die!"
(read "Ruby or your fired!") then you are forced to play the part
of the humble wizard who has develops a method for alchemy and
uses it to build up his portion of the kingdom along with anyone
else who will join in.
But, in the case of Perl, you probably feel more like Noah, knowing that
Perl usage is going to bring (financial) destruction to the company and
using the direct approach you will probably be as successful as Noah. ;)

I just wrote a long message to a friend about this issue. I quote 
here what I can:

> Why would I want to switch from PERL to Ruby?
 
Short Answer: 
  Because Ruby is better and Perl is harmful. Or better
  yet, because Perl cannot match what Ruby has to offer.
  But, this needs more explanation.

Long Answer:

No amount of physical evidence (or particular 
attribute of the language) is going to make or break the 
decision. You make the decision by your gut and then find 
evidence to support that decision. The only trick is to 
get others to make that same 'gut' decision. :)

Most everyone I know using Ruby is doing so because 
they were looking for a good scripting language or 
one better than Perl. If a person is happy with Perl, 
then it would be interesting to know why, but I would 
not try to convince them to use Ruby, they have much 
bigger problems. ;) However, because an organization 
uses Perl, that doesn't mean that the organization is 
happy with the outcome. It usually is because that is 
all it knows.

However, there are definite reasons why Ruby is an optimal
language for the type of scripting work that is done
in the XYZ industry. But, I don't think that just
listing these here is going to help you make a case
of why to switch.

At YYYY, I have been asking myself questions similar
to your original question[1]: 

  "If I were my boss (or anyone at YYYY), why would I 
  use Ruby (over Perl)."
and
  "Why should I listen/believe this Jim Freeze guy about
  Ruby being better than Perl or Python?"

Well, my current belief is that I can only answer this 
question by action. Words alone won't do it. So, in an 
effort to do this, I have been translating some existing 
code from perl to Ruby. My experiences, I believe, are 
equivalent to what you will find. Let me itemize a few:

  1) Perl scripts (PS) are not centralized in their location
  2) PS are not uniform in handling command line arguments
  3) The PS use one primary data structure, the Hash (the array is second)
  4) Converting the Perl code to Ruby without thinking reduces code size
     by about 30%
  5) Refactoring the converted code usually yields a 50-60% reduction in
     file size with an increase in readability.
  6) The PS's have no unit tests
  7) It is difficult to debug the PS's, even with printfs. (Perl doesn't have
     the Ruby's equivalent of inspect)
  8) The Object Oriented system of Perl is primitive - all methods are class methods.
  9) The concept of IP library as we had at YYY has never occurred
     to anyone I have talked to at ZZZZ.
 10) Code sharing has never occured to anyone at YYYY. This is a direct
     result of using Perl. Yes you can share packages with perl, but it is 
     not usually done in a corp environment. The language does not
     encourage it. For some reason, pointing this out is not a strong 
     convincing point. For most, the response seems to be, well we can 
     do better and we should. But, they never do.
 11) Only one Perl package was being used that did not exist in Ruby, the
     GDS parser. I am in the process of porting it to Ruby now.

In the process of converting the Perl code and adding unit tests,
I have found bugs (some innocuous, some not) and design flaws and
weaknesses. The design flaws and weaknesses are mainly related to 
the Hash centric nature of the Perl code and the lack of a true OO 
system in Perl.

The logic bugs are mainly due to lack of tests. The scary part is
that some of these apps have been around for a while and are considered
to be working bug free.

The best way to convince someone (to at least listen to you) is to port 
some code and look at the results.

Before the port I can say:

  Your Perl code most likely has bugs, you should switch
  to Ruby which is easier to debug and maintain. (not very convincing)

After the port:

  Your perl code has bugs. The Ruby port has fixed those bugs and has
  unit tests to ensure the correctness of the application. Which would 
  you rather use and maintain? (more motivation now to listen and
  see the benefits of Ruby with a testing and IP sharing framework.)

> We have a large base of PERL code already.
> I need good reason to overcome the inertia.

The important thing to realize is that a large amount of Perl 
code does not mean there is any inertia in the corporate 
development or runtime environemnt. We have a lot of perl code
at YYYY, but it is scattered and often teeters between
being broken and running without any issues. I personally would
not describe this as having inertia, more like a house of cards. :)

Stepping up to a better language and phasing in a better way of 
doing things does not take away existing value.[2]
So, even if some inertia exists, the only inefficiency is in not
adopting the better method. So, possibly, the better question
to pose is, Can Perl meet what Ruby offers? For a number of
issues important in a corporate setting, the answer is clearly no.

  - support for unit testing and unit-test framework exists
  - code is easy to read
  - code is easy to maintain
  - code is readily sharable
  - code is scalable to multiple developers
  - code is scalable in speed - easy to drop down to C code

BTW, I have created OptionParser, Application and project_config
and am releasing them open source. These will definitetly help 
you in your deployment efforts.

Footnotes:
  [1] At YYYY, I was told they had a recent experience with Python
  where they tried to get it installed throughout the company
  and replace Perl, and that effort failed. I was asked how is 
  Ruby different than Python and why would it succeed. The question
  at the time was mostly rhetorical, but the point here is that
  successful deployment is more based on user support than language
  features. You just need to make sure that you have a language
  that does not irritate the users (both Perl and Python have
  proven themselves capable of irritating the majority).
  But the reason Python failed at YYYY was not because of the
  language but because of the deployment strategy and user support.
  Consider that John Doe and others tried for a total of three times 
  to get a scripting repository deployed at ZZZZ and failed, whereas
  Ruby and the IP library has succeeded. I knew we would succeed
  because we gave the engineers what they wanted.

  [2] Only a few organizations understand the imperfection of humanity.
  There is probably not a single line of text in this email that
  I have not had to use the backspace key to correct a mistake.
  The same goes for code. It is unlikely that there exists a single script
  greater than 100 lines of code that does not have an undiscovered
  logic bug.


> Off the top of my head:
> 
> 1)  C extensions allow us to easily integrate with external existing
> software, but I don't know how Perl or Python does in that respect.

Perl is difficult. I have heard the same for Python, maybe more so.
> 
> 2) Built-in support for unit testing.
> 
> 3)  Extendability / maintainability, but I can't think of anything
> objective to say here
 
Depends upon the hostility of the person you are talking to.
Take two programs - one in Perl and one in Ruby - create a
five question quiz of various aspects of each program and
have non-programmers take the quiz. This will give you some
numbers of readability.

> 4)  DRb is very useful in developing distributed applications.  I'd
> imagine Perl and Python have similar features, but don't know anything
> about them.

Good luck. Let me know if I can be of more help.

-- 
Jim Freeze
Theory and practice are the same, in theory. -- Ryan Davis