* Joe Van Dyk <joevandyk@gmail.com> [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
>. 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