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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ...it's already having a great effect on Perl 5 development. For example, in the deprecation of pseudohashes, and in the incorporation of the // operator in 5.10.

    And useful (and usable) parts of Perl 6 *are* available already in the form of Perl 5 modules like:

    • Perl6::Parameters
    • Perl6::Interpolators
    • Perl6::Currying
    • Perl6::Gather
    • Perl6::Placeholders
    • Perl6::Form
    • Perl6::Say
    • Perl6::Slurp
    • Perl6::Export

    To say nothing of the way that my own on-going struggle to implement the Perl6::Rules module is u

      • Perl 6 won't take that long, even though it's far more than twice as powerful.

      Could you nail this down for us? Is Perl 6 180% more powerful or 400% more powerful than Perl 5?

      Or are linear relationships of power difficult to quantify at this point? Could it be that the power of Perl 6 is ever increasing, exponentially proportional to the distance of its first release date?

      It must be frustrating indeed to have to meet the goal of producing a language that is "far more than twice as powerful" as Perl 5,

      • It must be frustrating indeed to have to meet the goal of producing a language that is "far more than twice as powerful" as Perl 5

        That was never a "goal"; it's merely an observed outcome.

        And, of course, it *is* nonsensical to try and nail down the exact increase in "power". But given that Perl 6 adds features like:

        • hyperoperators
        • junctions (superpositions)
        • coroutines
        • strong typing
        • subroutine overloading
        • multiple dispatch
        • declarative parameter lists
        • named parameters
        • currying
        • properties and t
          • Nevertheless, thanks for pointing out the absurdity of trying to quantify such improvements.

          You're welcome.

          I am, however, reminded of a quote that might be appropriate:


          A language that doesn't have everything is actually easier to program in than some that do. - Dennis M Ritchie
          • A language that doesn't have everything is actually easier to program in than some that do.

            Actually, I don't think that's appropriate at all. I doubt that many here would seriously argue that C or sh is actually easier to program in than Perl 5 (for most tasks). And yet Perl 5 has far more features than C or sh.

            How much is "in a language" is very close to irrelevant. What matters is *what* is in it. That's why DMR says "some that do". It's not the magnitude of the feature vector; it's the direction it

              • Actually, I don't think that's appropriate at all. I doubt that many here would seriously argue that C or sh is actually easier to program in than Perl 5 (for most tasks). And yet Perl 5 has far more features than C or sh.

              Well, I guess it's a good thing that neither I, nor as you point out, Dennis Ritchie, makes the point that a language that has more features is necessarily harder to program in.

              I was reminded of the Ritchie quote, however, because, to me, you seemed to be implying that a language that h

              • Look, I'm not really against Perl 6, but I am skeptical. The whole process seems to be the opposite of what has made Perl 5 so successful, incremental development with rigorous field testing.

                But that's precisely how we *are* developing Perl 6. Almost all of the new features we're folding in are either taken directly from, or refactored from syntheses of, existing modules or programming idioms. Here's a partial list of the rigorously field-tested modules whose useful functionality we are in