All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

This, incidentally, is why I'm bullish on Perl 6. It appears to solve most of my Perl 5 problems. Tim Bunce has already mentioned that he plans to port DBI.pm to Perl 6, a Perl 6 CGI.pm won't be far behind (it might even be first) and I suspect that a few other core tools will quickly get ported. With those in place, and given that the real value in a business is the in-house code, if Perl 6 is stable and runs as fast as we suspect, maybe I won't be eyeing Ruby with such longing.

What are you expecting to get out of Perl 6 that you won't get from Ruby, other than a speed advantage?

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.