Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Didn't We Use The Phrase "Reverse Sublimation" a While Ago? 20 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • 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

    • However, Perl 5 has also adopted Perl 6's useful bits.... Unless Perl 6 has some kind of killer app....

      Better internals? Pervasive OO? Mutable lexical grammars? Working exceptions? NCI? Macros? JIT? Bytecode? Grammars? Serializable continuations? Multidispatch? STM? Hyperoperators? Pervasive laziness? Immutable sigils? True reference context? Aliasing and binding? Few globals? A robust parser?

      I can think of two reasons why Perl 5 will never get many of the interesting and useful features of Perl 6 (some of which already exist in one or more implementations).

      • Here's my perspective on these things, as someone who uses Perl regularly, and contributes to CPAN but not to the Perl core:

        • Better internals? Not directly relevant to me as a Perl programmer.
        • Pervasive OO? I'm not pervasively OO either, so it doesn't matter.
        • Mutable lexical grammars? Nice.
        • Working exceptions? Perl 5's exceptions work well enough for me.
        • NCI? If it is better than Inline::C.
        • Macros? Nice.
        • JIT? Bytecode? If they reduce the number of times I have to drop down to C for speed.
        • Grammars? Nice.
        • Se

        • It would be great if you were less coy about your two reasons.

          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.

          Most of the features in the list I quoted are impossible w

          • 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.

            • Perl 5 certainly hasn't ground to a halt.

              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.

              Don't forget to account for the fact that the "stable" release of Pe

              • 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 "Hea

                • 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'm saying that somehow these substantial internals changes keep happening fast enough to adopt Perl 6 features at a decent rate.

                      Smart match still isn't finished. That's why 5.10.1 isn't out, nine and a half months after 5.10.0.

                      [Has] anyone reported your feature having broken actual cod

                    • 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.

                      As for the new regex constructs in 5.10, there isn’t a single p

                    • 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.

                      Admittedly it's unlik

                    • 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

                    • Like I said before, this is an empirical question.

                      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.

                    • Screw it. Consider me browbeaten.

            • Perl 5 certainly hasn’t ground to a halt.

              No, it’s just very, very stable.

        • You only think better internals aren't relevant for you. IF you want bug fixes to perl, you want people to be able to fix bugs without jury rigging.

          You'd probably want bytecode too. I don't hear any Perl programmers seriously saying that they want to recompile everything on every invocation of their script. Want a faster Perl program? Get rid of the compilation step.

          You get the benefit of a lot of things you don't care about.

          • I'm aware of the benefits of these things, but none is a killer feature. Maybe "don't care about" is the wrong phrase -- I just mean that none of them would be a significant factor for me in choosing a language.

            Yes, the complicated internals make bug fixing more difficult. On the other hand, the core code is mature and battle-tested, so it has few bugs, and most of those are in weird corner cases.

            And ahead-of-time compilation, whether to bytecode or native code, has some advantages. But the time only I h

        • All of the things you casually dismiss as “doesn’t matter to me directly” certainly do matter to you because they translate directly into how far and how easily the platform reaches. How about being able to do number crunching with code much closer to raw Perl 6 than PDL-using code is to raw Perl 5, with much less effort than PDL took to write? That would most certainly be directly relevant to a whole lot of people in the trenches, even though they won’t personally get dirt

          • This is why I distinguished between "doesn't matter directly" and "doesn't matter." I'm not saying the indirect effects aren't there, I'm saying it's hard to predict them.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.