Slash Boxes
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.
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

      • 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
        • 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 have been annoyed by startup time was when using a large Parse::RecDescent grammar. Usually compilation time is swamped by the time to either load my data or process it. A working dump/undump would probably be most useful to me, but I gather that's hard to do.