From: Bryan Murphy <bryan@...>
Date: 2001-08-09T05:01:05+09:00
Subject: [ruby-talk:19389] Re: Perl/Python/Ruby common backend (Parrot	, can Ruby play too?)

>
>
> Even though I like to be able to choose which language to use: the 
> problem
> is the boss may see that as a potential maintenance nightmare because
> the more languages you use the harder it gets to maintain.
>
> Christophe
>
Sure, that's a potential problem, but that is one that is easily settled 
by a good boss who
wouldn't let you do it in the first place.   Any boss who let's his 
developers develop code
in multiple languages simply because they want to is a bad boss and that 
project is going
nowhere.  If you are using multiple languages, there better be good 
reasons to be doing
that.

That is a nice feature for programmers only, but imho that's not going 
to be the selling point
to most corporations.  What is going to be the selling point is this:

Boss> This perl code is a maintenance nightmare... We are spending way 
too much money
trying to keep these sites up.  Tell me how we can fix this.

Employee>  Well, we could rewrite everything in Ruby.  Ruby is a very 
clean consistent
OOP language that leads to code that is easier to maintain than Perl.

Boss> That would take too much time.  We can't afford a complete 
rewrite.  Give me a better
solution.

Employee>  Well, Ruby, Perl, and Python share this common backend called 
Parrot.   This
allows an incredible amount of integration between these languages.  We 
could rewrite our
mission critical components in Ruby, do any future development in Ruby, 
and the remaining
Perl components will continue to run just as they always have before. 
 In fact, we could even
even ease the transition more by using the Perl base classes as base 
class for our Ruby code.

Boss> Now you're talking.  Let's do some budget analysis and pass this 
idea up to upper
management.

That is the kicker.  I bet there are a LOT of companies out there with 
old, bloated, unreadable
Perl code that are just dying for an easy way to migrate away from Perl. 
 My last job was
95% Perl.  I bet a lot of that code is still around.  I know some of it 
is absolutely terrible, but
I'm sure my ex-boss feels rewriting all of it isn't a feasible option 
(he was, afterall, an extremely
competent boss).   And I know they still suffer when they have to modify 
old Perl code.  I worked
there for three years and had to do it all the time myself.  It sucked.

So, basically, it comes down to good management.  :)