NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Why wait? (Score:2)
What are you expecting to
The answer should be obvious (Score:1)
An upgrade path. (Not that a speed advantage is a bad thing with the amount of traffic we have...)
Seriously where I work we have about 3 years of Perl code accumulated. Suppose that Ruby is 30% more productive than Perl. Then (by a naive calculation) if we switched, it would be 10 years before we had caught up and passed where we are now. That's not even counting the mess of going through a period with 2 versions of the same software. Making decisions with a 10 year time horizon to pay-off is risky, because a lot can change in that time.
Of course that is an unrealistic calculation. Because in 10 years both Rite and Perl 6 will come out. So let's assume that both Rite and Perl 6 are 50% more productive than Perl 5, that Ponie (Perl on Parrot) becomes usable in 2 years, Rite is released in 2 years, and Perl 6 comes out in 5 years. (It is supposed to be a year out, but I never believe those estimates.)
Now let's compare switching with remaining with Perl. Yes, I know how silly the numbers I'll produce are, but they capture something important. At year 0 we have 3 years of Perl development, vs 0 years of Ruby. In 2 years we'll have 5 years of Perl development vs 2 years of Ruby, which is like 2.6 of Perl. Then the Ruby track switches to Rite, and Perl to Ponie (no development improvement. 3 years later, 5 years from now, we have 8 years of Perl development vs another 4.5 equivalent on the Ruby track, add that to your 2.6 and we have 7.1 equivalent years on Ruby. Now the Perl folks switch to Perl 6 and Perl maintains about a year headstart. Plus with Perl there never was significant business disruption.
What these made-up numbers capture is the logic which causes existing projects stick with an alternative even if they think that that alternative is inferior. Even if the other technology is superior in the long run, the difference has to be phenomenal for you not to get killed in the short run.
And even if Perl 6 comes out in a reasonable time frame (a big if), which syntax would you prefer?
Perl 6 is now being estimated at a year away. I don't believe those estimates. But as the above indicates, even a promise that there will be a good alternative with a smooth upgrade path 5 years out is enough to clinch sticking with Perl if you have enough of an installed base.
Of course if you are starting from scratch, then choosing to go with Perl because of a promise of Perl 6 later would be silly.
Besides, wouldn't it be nice to play with a decent thread, semaphore and mutex model *today*?
This is your worst argument. Ruby does not have a decent threading model. The only thing that might make me consider going multi-threading is to continue processing when doing a slow blocking operation like a database call. Ruby implements cooperative multi-threading internally, and so doesn't offer that.
Cheers,
Ben
Reply to This
Parent