in reply to Back to the __future__

But deep down I expected the significant future to be Perl 6.

And I still do. I might be on a lonely position here, but I do think of Perl 6 not only as a successor for Perl 5, but also as a successor for Ruby, TCL, Lisp and a number of other dynamic languages.

We need to start giving Perl version numbers against CPAN modules

FWIW all of my CPAN modules already declare a dependency on a minimal Perl version, by having perl: 5.006001 in my META.yaml, and 

require
5.006001;

[download]
in Build.PL.

So maybe you should be more specific: maybe it's time to track lower and higher version constraints, and make parts of the infrastructure(*) aware of it.

(*) intentionally left vague here, because I'm not yet sure exactly which parts need to be changed.

Let me tell you a short story. Nearly exactly two years ago I uploaded the first Perl 6 module to pause.cpan.org. I had carefully declared a minimal Perl version of 6.0.0. I joined #toolchain on irc.perl.org in order to talk about any problems that might occur.

As one might expect, the attempt didn't work out too well. The indexer didn't know what to make of the Perl 6 Pod dialect, so no docs showed up on search.cpan.org. But still the tarball got distributed to the CPAN mirrors, and was available for download.

This disheartening part was that the overwhelming majority of #toolchain wasn't interested in making anything Perl 6 related work, but demanded that I didn't break anything Perl 5 related. I didn't plan to, and as far as I can tell, I did not. All my plans (which I tried to discuss there) had carefully been designed not to break anythiing for the Perl 5 folks.

All I had was one distribution on CPAN that wasn't indexed correctly, and that no perl 5 tester could run, because their perl version was too low. Still, when I rejoined #toolchain about 15 months later, a pretty vocal and influential member of infrastructure hackers remembered me as "the guy who broke CPAN"

As a result, Perl 6 has started to develop it's own, albeit pretty primitive, module infrastructure in the mean time. Some people from the Perl 5 community did seem genuinely interested, and reminded me not to repeat the mistakes that were made in connection with Perl 5's packaging system, without being able to actually point to concrete mistakes.

When I now read that Damian Conway (and maybe others) want Perl 6 modules on CPAN, I wonder if they believe in fairytales, or if they are connected to a different reality than I am, or if I simply met the wrong people when I started my attempt two years ago, or if something substantially has changed in the mean time.

I'd very much like to see a reuse of resources when building a module distribution system for Perl 6, and I'd very much like to see that happen soon. If anybody can propose concrete steps to drive that effort, I (and many other Perl 6 hackers) am willing to do my best.

I'm just weary of two things: handwaving like "we must fix CPAN", and overdesign that leads to too much effort before a simple installation of a Perl 6 module can actually happen.

Perl 6 - second systems done right

Replies are listed 'Best First'.
Re^2: Back to the __future__
by locked_user sundialsvc4 (Abbot) on Aug 18, 2011 at 23:20 UTC

    To me, what is remarkable, important and lasting about Perl is not the language itself, but the CPAN library.   Many years’ worth of rugged, battle tested software that works.   That is what makes Perl different ... as I discovered first hand while briefly consulting for “A Popular Powerful Legendary Enterprise” that wanted for some reason to replace its Perl Software That Works™, with Something In Ruby.   Oops!   Although Ruby at first blush appeared to have an equivalent package to do many things, it often didn’t provide the functionality that was needed right-now, and furthermore the packages had a rather disagreeable number of flaws.   The upshot (at the present day, of course... the Ruby teams are no slouch and I’m not suggesting any such thing) was that while the Ruby language might (?) have been Better,™ the project was not well served by the Ruby system in its present condition.   Of course it could happen to anyone, anywhere, in any language system fill-in-the-blank, but ... the Perl library spoils you quick.   It is of course the product of many more years of effort than is Perl Itself.

      “The trick,” for the Perl-6 project, is how to make it a different-and-better language while also allowing it to be source-compatible in some way with its important installed-base ... namely, CPAN.   There is too much in CPAN to allow all of that stuff to be “rewritten.” So, there is a formidable engineering challenge here.   Existing projects such as (specifically...) Moose do show what can be accomplished, even in the context of Perl-5.

      So, IMHO, “Perl-6 must be more than a forward step.   It must be a broader step.”   If it were merely to be thought of as “a new and therefore better language,” well, we’ve had all of those things before.   We’ve got them right now.   Ruby.   Haskell.   Your Opinion May Vary.™   All of them, nevertheless, different, and all of them rebuilding from scratch a thing that Perl has spent the last X years already doing.   So, the engineering problem, as it turns out, is in the existing code.   The existing shared code.   The easiest approach of course is to “start with none,” but that is throwing away the baby.   The language isn’t the baby; it isn’t a thing that can be “improved upon” in isolation.   The commercially valuable thing is CPAN, not to mention millions of vital “legacy code” installations that are literally hauling the freight and paying the bills.   Hence, my observation that the approach must be a broader approach:   one that encompasses what exists now, and which elaborates upon it without repudiating it.   We cannot say, “that was then, this is now.”   We need, “that was now, and this is also now.”   A vastly more complex software-engineering problem . . .

Re^2: Back to the __future__
by Anonymous Monk on Aug 19, 2011 at 03:17 UTC
    When I now read that Damian Conway (and maybe others) want Perl 6 modules on CPAN...

    If you've read that, then I have been either misquoted, misattributed, or misunderstood.

    I want Perl 6 modules on 6PAN, or C6AN, or CPAN6, or some other suitable parallel to CPAN. At the moment, that repository seems to be named "GitHub", but I still long for a more PAUSE/CPAN-ish front end to it.

    I certainly don't want Perl 5 and Perl 6 on a single undifferentiated repository. Half of the Perl 6 modules I've written are direct ports of my existing Perl 5 modules, with identical names and similar APIs. There is no way they can coexist with Perl 5 modules...at least, not under CPAN's linear notion of "latest version" (which, BTW, I wholeheartedly approve of as being much more appropriate for the majority of CPAN users).

    Damian

[reply]

      Sorry, I didn't mean to misquote you, since I couldn't attend YAPC::EU, all my knowledge is from second hands.

      Yes, we need work both on the frontend and backend for a Perl 6 module solution, it will be interesting to see what we can come up with.

      While we are at the topic, are your Perl 6 modules available somewhere for the general public?

      Perl 6 - second systems done right
[reply]
        Sorry, I didn't mean to misquote you, since I couldn't attend YAPC::EU, all my knowledge is from second hands.

        Not a problem. I just didn't want the Chinese whisper to become offical history. :-)

        While we are at the topic, are your Perl 6 modules available somewhere for the general public?

        IO::Prompter is: https://github.com/colomon/io-prompter

        The rest will go up soon...I'm waiting for the NOM branch to be out, so I can remove several detours around previously missing constructs.

        Damian
[reply]
      I didn't know what to make of your YAPC::EU keynote. I kept wondering whether I was listening to the 2011 Damian, or a time warped Damian from 2004.

      I'm with Jesse when it comes to view of Perl 6. It's a nice research project. Now let's do something useful with/to Perl 5.

      As for the name. I actually think the name "Perl 6" hurts "Perl 5". While for the incrowd it's clear what the differences between perl6 and perl5 are; how they relate to each other; and what Larry's feelings are, the rest of the world doesn't have that knowledge. They see numbers and think Perls numbering scheme is sane, and acts like the rest of the world. And hence, they're not considering perl5 something to invest in -- they'll wait for perl6. But I also realize that any discussion here about it is fruitless. Unless you can convince Larry, it's not going to change (Rule 1). And in Asheville, he made it quite clear he hasn't changed his mind yet (Rule 2 isn't being invoked at the moment).

[reply]
Re^2: Back to the __future__
by cdarke (Prior) on Aug 19, 2011 at 10:10 UTC
    I did not intend to undermine the work you and others have done on Perl 6. The fact that there is a future vision for Perl 5 should take some of the pressure off Perl 6. I expected too much from Perl 6 in an unrealistic timeframe - my fault not yours.
[reply]

In Section Meditations