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.
  • I heard that about a year ago, a language that had been in use for something like twenty years added a bunch of new keywords, broke binary compat, and even changed some of its operators. Next, there's talk of changing how it handles Unicode, changing the set of first class data types...

    For Pete's sake, WHEN WILL PERL 5 BE FINISHED?

    --
    rjbs
    • The developers of my pwecious don't seem to have any trouble finding real-world use cases. ^.^
  • The top five things holding me back from using Rakudo for anything but experimental playing with Perl 6 are (in order of imporatance):

    1. lack of lazy evaluation
    2. s/// is not implemented
    3. it cannot be installed ("removing or moving the build tree will cause the binary to stop working")
    4. I cannot easily tell what parts of the spec are implemented and which are not
    5. The REPL has executes every line in its own scope making lexical variables (and therefore the REPL itself) next to useless.

    I may be wrong abou

    • All of these issues are slated to be resolved by the time Rakudo Star is released. Indeed, I expect that all of them except for #4 will be resolved by the September 2009 compiler release.

      #2 can already be done in current versions of Rakudo, just use .subst() instead of s///. The s/// form should be available when we start using the STD.pm parser in Rakudo, currently planned for December 2009.

      Pm

      • That makes me happy. It would be nice if there were an article about what is planned to be (or not be, if that is shorter) in Rakudo Star. Of course, it is entirely possible there is already a road map on a public site that I have not seen yet, and there is still a lot of time until Spring.

        I am not worried about the spec (and therefore the implementations) changing or growing; I am worried about how much of what is currently spec'ed will be implemented by the deadline. A Perl 6 implementation that can't

        • It would be nice if there were an article about what is planned to be (or not be, if that is shorter) in Rakudo Star.

          We worked on this at YAPC::EU in Lisbon, I'm currently in the process of writing it up to be somewhat coherent and understandable. Stay tuned.

          A Perl 6 implementation that can't do what the spec says is Perl 6 doesn't seem to be a real release to me.

          The whole point of Rakudo Star is to say "this isn't all of Perl 6". Anyone that gets Rakudo Star and expects all of Perl 6 to be implemente

        • It would be nice if there were an article about what is planned to be (or not be, if that is shorter) in Rakudo Star.

          Patrick and I discussed this at OSCON. Our rough plan is that I'm going to be helping track and communicate what is in Rakudo Star, and what isn't, and how close we are to having those things ready to go.

          --

          --
          xoa

        • I see it as being promised Perl 5, but having to settle for Perl 4.

          Even Perl 5 isn't "finished" though. If the original Perl 5 had been the ultimate destination then everyone would have been sat in the same place for the last 15 years.

          Perhaps it's better to imagine the Perl 6 spec as being analogous to what people might have envisioned for, say, Perl 5.10. The original Perl 5 didn't implement all the features from that "spec" (like given/when, or say), but it was still usable. The Perl 6 spec will inevitably evolve in the same way that the Perl 5 implementation has, and

          --
          recoil
    • Actually, what I want from Rakudo right now is just more speed (like 10-100x the speed it is now) so I can run it and crash it faster/more often :-). I guess to be comparable to Perl5 we need like 1000x times the current speed, but I'm willing to settle for less.
  • perl 3 was a language that was useful for production work.

    Through the point releases of perl 3 and perl 4 that language got extended drastically - always in a 99.9% backward compatible fashion for each step, and always being useful for production work.

    perl 5 was only 99% backward compatible, but turned the language upside down and extended an order of magnitude, and, after the first couple of point releases worked the kinks out, was useful for production work (in an order of magnitude larger number of areas
    1. Perl 6 isn't a product, but a project with no single delivery date. Think about the difference wetween a coffee mug (product) and the english language (project.)
    2. When is the english language "finished"? Would you put off learning english until someone said it's spec was "finished"?
  • I really liked the description you gave during the Rakudo BOF on YAPC::EU. Maybe we should use it as a subtitle of Rakudo:

    Rakudo, implementing a useful subset of Perl 6

    Later I thought that by using the name Rakudo we can actually avoid the Perl 5/6 trap and the "when is Perl 6 going to be ready?" trap.

    Maybe the disconnect between Rakudo and when is "Perl 6 going to be ready" could be increased by giving small and increasing version numbers to the Rakudo releases - even starting by the next one - and h

    --
    • If people are going to put thought and effort into understanding if Rakudo is useful for them, I'd like them to do so based on the ratio of planned and implemented features important to their work, not on lengthy explanations of magical version number schemes.

      It would be a shame to fall into the magical version numbers trap while trying to avoid the magical version numbers trap. ("Rakudo 0.2 in April? Those fools! Can't they release software? Everyone knows that software isn't usable for anything until

  • I'm glad to see you responded to gdonald's questions, addressing all the key points, including the common misconception about what Rakudo * is and is not, Perl 6 being 'finished', et. al. Nicely done!
  • Well color me contradictory and call me flame-bait, but I'm really annoyed by the original blog posting, as well as this follow-up article. Am I the only one? In truth, you've answered a lot of questions for me. But it leaves open some more.

    What first got me going was when people don't ask the *right* question, your seeming to come off like someone who responds to the question, "Can I have a cookie?" with "Don't you mean *MAY* I have a cookie?" I'm sorry you don't like the word "finished" but as you say you

    • Perl 6 should have a release date. You prioritize what will go into that release, you implement it, and then you release it.

      I believe that this is exactly what the Rakudo Star announcement says we are going to do. It names a release date, says that we will prioritize what will go into that release, gives a criteria by which we will come up with priorities, and says we will focus our efforts over the next eight months on implementing those priorities.

      Look, if you want to complete *ANYTHING* -- a language

    • Virtually nothing new has gone into the Perl 6 spec for a long time. The big new stuff came along at the beginning - the time involved reflects just how big and new a lot of these things are, and how difficult it is to get everything into a coherent sort of whole. This is not navel-gazing or ADD or being distracted by shiny things. The shiny things are here, they're in the spec, many of them are in the code. Many of them have rough edges and we're still trying to get them to fit together into a nice pattern
    • Perl 6 is alive. A trek? No. Rakudo is a building site for a fantastic new structure. And building sites look messy, outsiders see activity but cant distinguish it from progress because they are outsiders, the architect's plans are being adapted to reality whilst retaining the overall concept, and the exterior will only be visible and shinny immediately before its ready to be used (and even then the plumbing usually goes wrong on the first day).

      It seems to me to be honest and respectful of the building's u