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.
  • One thing bugged me: (Score:3, Interesting)

    by Matts (1087) on 2002.04.27 10:39 (#7639) Journal
    "Of course, you'll never actually have to write anything like that yourself, since the Perl 6 distribution will come with a fully generalized source code translator program."

    I wish Damian and others would stop saying that. Perl 6 itself is completely vapourware, so lets not build vapour on top of vapour, please. The Perl 5 translator module is the least appealing job of all the possible perl 6 tasks. So it's likely to get done last, if at all.
    • The Perl 5 translator module is the least appealing job of all the possible perl 6 tasks.

      Oh, I dunno. Writing the Perl 6 parser is going to be an incredibly unpleasant job for someone. (That's why I really wish people would stop claiming that the Perl 6 syntax is going to be "more regular". It's not. It's going to be harder to parse than Perl 5. Believe me, I've tried.)

      The translator shouldn't be that bad. If you can go from Perl 5 to Python [], I don't see going from Perl 5 to Perl 6 to be that difficult.

      Of course, it'll only be useful if someone ports all those XS modules that all our code depends on, but we can get to that in time...

      • The Perl 5 translator module is the least appealing job of all the possible perl 6 tasks.
        Oh, I dunno. Writing the Perl 6 parser is going to be an incredibly unpleasant job for someone.
        So I guess this is why we haven't seen any code written other than the core, huh? Sheesh. It's such a bummer. I was looking forward to a new perl.
    • by hfb (74) on 2002.04.27 13:04 (#7646) Homepage Journal

      Shameless self promotion should be familiar to you and many others as, at least in US parlance, to talk about something makes something real even if it isn't. People can say anything they want about Perl6 as, until it's delivered, there really isn't anything to discuss.

      The biggest mistake was making it a 'community rewrite' since it will be the most successful death by committee the software world has ever seen. Hundreds of little project managers cackling upon the flames of hope and good intentions. Everytime someone even mentions Perl6 these days it causes a tiresome, boring pedantic conversation that is mostly meaningless and unproductive and this is just in vapour, just wait a few more years and see what the prodigal language brings. Hopefully my transition to ruby will be complete by then.

      • i will ask u again when we go "next-turn" i.e. when other languages start coping Perl6 features en masse as they did with current Perl to become popular :")

        And u forgot the main thing why Perl community use Perl ...
        !!! Because it is FUN !!!
        If it was not fun for you shouldn't learn it, in the first place..
        (about learning new language it is not that hard to learn new language those days, the hard/time-consuming thing is to learn technology around it i.e. object-repositories, OSes and Products API's ..etc).
    • The perl 5 front end is no less appealing than most of the other work involved in parrot--certainly not annoying enough to make a difference. It'll get done.
    • by gnat (29) on 2002.04.27 13:09 (#7648) Journal
      "Perl 6 itself is completely vapourware, so lets not build vapour on top of vapour, please."

      I have to admit that I get a little frustrated by the hypocrisy in the "perl6 is vaporware" statement. Sure there's no code. We're designing. You remember design. It's what we get flamed for if we don't do. Oh look, now we're getting flamed for doing it.

      We could have leapt right in and started coding. We'd certainly have some parsing code and a language of sorts by now. But would the pieces fit together in any planned way, or would there be the same mixture of frustrating edge cases that crop up in perl5? I'm picking the latter.

      As for "let's not build vapor on top of vapor" ... the translator has always been just as much a part of the perl 6 plan as the perl 6 parser. We're not adding plans for anything--we've always said that we'll need to translate perl5 to perl6. You might as well say that "better object support" is "building vaporware on top of vaporware".


      • > I get a little frustrated by the hypocrisy
        > in the "perl6 is vaporware" statement

        You tell 'em!

        To all the perl6 nay-sayers: the lack of respect shown to those pouring their hard work and precious time into this project saddens me.

        OK, maybe that comment isn't really appropriate to direct to *all* the nay-sayers, but those who say "nay" without attempting to contribute constructively really chap my hide.

        Know ye contributors to perl6 that there is a large body of mostly silent programmers salivating
      • by Matts (1087) on 2002.04.28 4:41 (#7657) Journal
        I have never once argued for BDUF [] for the perl 6 process. And I've said before that I think the design by committee approach was a mistake. So I don't really think you can call me a hypocrite for that.

        I am however really mixed up about Perl 6. And for that I appologise to those working hard on it if I hurt their feelings - I should try and remove my passion from discussions of it. I think it has a lot to do with going through the almost exact same process as I went through as part of the Amiga community about 5 years ago. Ultimately I hope the same fate does not befall our tribe. I honestly didn't mean vapourware in an insulting way - if there were a better word to choose for a product being announced before anything tangible exists then I would use that.

        I don't think it's wrong to question the wisdom of our elders' choices in this process from the outside. Yes, I should probably be involved in the whole perl 6 development process. Were it not for this damned 24 hour day I surely would be. I'm sure there are others who are in the same boat as I am.
        • Perl 6 isn't design by committee, and neither is Parrot, so there you can feel comfortable. Or less uncomfortable, at least, and that's something.

          And while it's not wrong to question the wisdom of the choices made by the people in the middle of development, it's something to be careful about if you're not in the middle of that development. Not because criticismis inherently wrong--it's not--but because if you're not at least mildly up to date you'll find yourself worrying about nothing, or inadvertently bu
          • My feeling is that most of the Perl6 documents released to the public (Apocalypses and Exegeses) are written for a very small subset of the people using Perl on a daily basis. How about a status update on Perl6 for those programmers-who-aren't'superstars-and-probably-will-never-be?

            Gnat said in another reply that Perl6 is currently in the design stage and that is why there is not a rudimentary parser and the ilk. I understand the need for time to get the design right but the timetable for the design table s
            • I've been trying to get things out in The Perl Review [] but that's not enough. Bryan Warnock's doing perl6 list activity summaries when he's got the time, but like all volunteer activities the real world sometimes gets in the way.

              I'll see if I can't get more frequent updates as to what's going on posted to use.perl. Perhaps a regular Q&A session, too.
    • Some thoughts:

      1. A Perl 6 to Perl 5 tranlator is certainly non trivial, but not exactly hard. Remember: the translator is not forced to write idiomatic Perl 6. So, all we need to do is fix the funny characters, fix open to use the new returned file object syntax, change special variable names, a couple of operators, and boom, your set. This seems like a long list, but since syntactically much is the same translator could (almost) be a dumb regular expression.
      2. I would write the dang thing if I knew anyt
      • The real interesting project is not the p52p6 utility, but porting Perl 5.x to Parrot. Perl programs that depend highly on eval will probably need at least a little non automatic porting. But by bringing Perl 5 to the Parrot Virtual Machine Perl 5 bytecode can freely comingle regardless. If language design goes bottom up Parrot will still be there, a virtual machine for Perl, even if it never delivers it's multilanguage promise, could at least give Perl 5 true garbage collection and an easier way to handle