From: ptkwt@...1.aracnet.com (Phil Tomson)
Date: 2001-08-09T08:58:28+09:00
Subject: [ruby-talk:19395] Re: Perl/Python/Ruby common backend (Parrot	, can Ruby play too?)

In article <LVgc7.5$jo2.1108@e420r-atl3.usenetserver.com>,
Bryan Murphy  <bryan@terralab.com> wrote:
>
>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.


The scenario you present (selling the common backend as a means for 
migrating to a different language) is indeed more viable than the one I 
presented, though I'm not so sure I would condemn the use of multiple 
languages in a department (maybe on a single project, yes).  Invariably, 
you'll have somebody in a department that will be an "early adopter" of a 
'newer' language (like Ruby or Python) because they recognize the 
benefits.  These early adopters tend to be a bit ahead of the curve and it 
can be beneficial to allow them to at least experiment - ultimately you 
may have a gain in productivity and better maintainability (such as moving 
from Perl to Ruby).  So, as the early adopter is programming his|her 
project in the new language, others in the group continue to use the older 
language on their projects until it becomes clear that the newer language 
used by the early adopter is a better fit (or not, if that's how the 
experiment turns out) and management decides to begin to migrate to the 
new language.  Not that most companies allow this kind of experiment, but 
apparently some do - otherwise how did Perl (introduced in 1988) or Java 
(introduced in 1995) become so widely used (or even C++ for that matter).
Of course, not all such experimentation is approved by management - how 
many Perl programmers had management's approval when they started using it 
in the early '90s? How many Java programmers had management's approval 
when they started using it in '96?

But the main point here is that a common backend makes it easier for this 
kind of experimentation to occur and could help newer 'better' languages 
to emerge, perhaps more quickly than they would otherwise.

Phil