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

It looks like it may be moving forward now, unilke 2001 to around 2005 or so. However, Perl 5 has also adopted Perl 6's useful bits -- "say," "//," named subpatterns, OO stuff (via Moose) -- and via Devel::Declare, may soon get named parameters as well. My wild guess is that Perl 6 will be officially done in 3-5 years. When it's done, Perl 6 will have to compete with a mature Perl 5 that has been consistently cloning many of its best features. Unless Perl 6 has some kind of killer app, that's a very, ve

Perl 5's internals are almost unmaintainable. Its internal API has leaked out through XS into the CPAN and the DarkPAN. That's problem one.

Problem two is that backwards compatibility overrides all other concerns, including problem one. P5P is almost entirely unwilling to consider potentially breaking the DarkPAN, so refactoring poorly designed or badly implemented APIs doesn't happen.

I agree that Perl 5 does move slowly, for the reasons you mention among others, but 5.10 was a big step forward from 5.8, so Perl 5 certainly hasn't ground to a halt. Perl 6 (whichever version) also moves slowly (or at least unevenly), and has much more ground to cover than Perl 5, which has been a mature language for many years. It will be interesting to see whether or not Perl 6 becomes mature before Perl 5 adopts most of its interesting features.

Given multiple years between major releases -- and I'll be charitable and say three and a half years, there's your deprecation cycle length. If you want to remove a misfeature of Perl 5 or its API, you're going to have to wait until April 2012 before you can start using the replacement in production.

Usually you have to give Oracle, SAP, BEA, or IBM millions of dollars to move software that slowly.

Given multiple years between major releases -- and I'll be charitable and say three and a half years, there's your deprecation cycle length.

Deprecation doesn't matter. If something is deprecated and removed, then if I am using it, some of my code will break (wasting my time), and if I am not, it doesn't matter to me.

This would make a very boring graph. Plot time on the X axis and the interestingness of the feature adopted on the Y axis and you'll see a flat line that suddenly asymptotes right at the "Heat Death of the Universe" tick.

I have no idea where you're getting this. Are you saying (with a straight face) that none of the new features in 5.10 (wait another few months and re-read this if you insist) were borrowed from 6? Or that no future release of Perl 5 can possibly borrow more features of Perl 6? Or are you just trying to browbeat me into dropping the subject? I have nothing against Perl 6, but it has to prove itself just like any other language (Python, Ruby, Lua, Haskell,...) as a replacement for Perl 5 as my main scripting language.

I'm saying that it's impossible to shoehorn new and changed features into Perl 5 without modifying the internals substantially. Given the strictness of backwards compatibility, that's impossible... at least without deprecating the changes through one stable major release cycle.

Even a feature as simple as the one I backported (!!!) potentially broke old code. I disbelieve that adding anything more complex would be free in terms of backwards compatibility, especially if it touches the parser.

I'm saying that somehow these substantial internals changes keep happening fast enough to adopt Perl 6 features at a decent rate. It's an empirical question whether or not this continues. Also, "potentially broke" is not the same as "broke" -- has anyone reported your feature having broken actual code?

I really don't mean this to sound like an argument from authority, but do you read p5p? If you do, then I really don't understand how you reach these conclusions. (If you don't, I wonder where you get your information.)

I don’t know about the decent rate. Most of the adopted features were either utterly trivial (say) or only half-adopted as a significantly semantically poorer version (~~). But there is a lot more in Perl 6 than those. And the rate of adoption is only going to slow down as easily adopted Perl 6 features start running out and the remnants get more and more intertwined with the richer, less ambiguous semantics of Perl 6.

Where I get my perl 6 information? I skim p5p sometimes (e.g. I read some of the posts on the regex work), but since I'm not a core developer, there's no sense in reading it religiously. However, I have read perl5100delta, maybe a few blog posts or articles, and some journals here, so I know about the new features. Heck, anyone visiting the front page of use.perl will see that poll that's been up forever. If you think I'm ignorant in particular ways, you'll have to be more specific.

Define "significantly semantically poorer." AFAICT Perl 5's smart match is a good adaptation of Perl 6's. Perl 6 has a richer type system, so its smart match has to do more things, which I would call "semantically more appropriate."

Of what does your "a lot more" consist? (God, proper English grammar is awkward...) And before you say "pervasive OO," remember that I'm not an OO dogmatist, so I don't care about that.

Like I said before, this is an empirical question. So far, the evidence is that Perl 5 can

I've already listed a subset of advantages Perl 6 has over Perl 5. You don't care about any of them. Bully for you. If your "empiricism" (or the fact that Perl 5 can't support them to the extent that Perl 6 supports them, which you right now admitted) suggests that they therefore don't exist, it's no empericism with which I'm familiar.

The point of this journal entry is ontological, not whether you care about any specific feature.