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.

Building a "useful Perl 6" 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Maybe I'm behind the times and this works, but lately it seems like enough of Perl 6 is there for me to mess around and have fun, except for one thing: I don't think I can do 'make install' and have it in my path, which leads to a few annoying patterns of behavior being required.

    I hope that whatever else you do, we end up with an installable Rakudo.

    Good luck!

    --
    rjbs

    • I'm pretty sure that will be done, because we have a branch for that already.

      If you want to help us, check out rakudo, then run 'git checkout ins2', and follow the usual build instructions. Then tell us if that worked for you, and if you can run a simple Perl 6 program with it (perl6 -e 'say "Hello, world"' or so).

      (I checked that it works for me with an installed parrot, but I didn't try to install Rakudo itself)

      • ~/code/hub/rakudo/parrot$ cd ../parrot_install/
        ~/code/hub/rakudo/parrot_install$ ls
        bin/  include/  lib/  share/  src/
        ~/code/hub/rakudo/parrot_install$ ./bin/perl6 -e 'say "hello world"'
        hello world

        Works. I should look harder at how to have it install to /usr/local, but cool.

        --
        rjbs

        • You'll be pleased to know that the ins2 branch has been merged into trunk, and that the August release of Rakudo can now be installed.

  • 1. If you need wiggle room, use Q2 2010. That's a part of why companies do it.

    2. Naming a release based on an injoke for a new language isn't very engaging or informative.

    • 1. If you need wiggle room, use Q2 2010. That's a part of why companies do it.

      "Spring" had a few other connotations that I liked for my purposes, but your point is well taken. After this week I'll likely just use a month to refer to the expected delivery date.

      2. Naming a release based on an injoke for a new language isn't very engaging or informative.

      * I think "Rakudo Star" probably has enough merits to stand on its own without the injoke.

      * It's really just a "working name" until/if we come up with one

  • well, do not use 1.0 for sure or we might have PR disaster, just like KDE 4.0 (that was release aimed at developers, but being .0 release, many users/reviewers tried it and were very disappointed. afaik fedora labeled and distributed it even as a stable release, so many users were f*d)
  • Give some thought to forward compatability. People will be much more likely to use "Rakudo Star" for real-world applications if they can be guaranteed that the version of the language they're writing to will remain supported after the language evolves in future releases. If upgrading Rakudo will break real-world applications because the language semantics evolved, that will discourage anyone from writing those applications in the first place, especially serious ones that can't necessarily be rewritten eve
    --

    Deven

    "Simple things should be simple, and complex things should be possible." - Alan Kay

    • I think you're addressing the more practical nature of Perl 6 which still seems premature, as I read this thread. There are applications to be written, libraries to be ported, packages to be bundled, books to be written, training classes to be prepared. Until it syntax/semantics are stable (not necessarily code stable) then it's pretty much impractical to do most of these things. And some have *long* lead-times (books, porting projects). Some can't be undone (releasing an app into the wild). Software h

      • So, riddle me this. What would an adult prefer: shoehorning all software projects into a 6 stage development model, or looking at the dynamics of a community and trying to find a development model that works well and produces the best result? Your stages are mighty fine for a lot of situations, but I'd hate to be as inflexible to think it's the only way to succeed.

  • Here, I'll explain since you don't seem to get it.

    When people ask "When will Perl6 be finished?", they want to know when there will be a Perl 6.0 release. Of course everyone realizes development will still continue, who ever said it wouldn't? The question doesn't imply that at all, at least not to me.

    If you don't want to answer the question then don't. But don't act like it's some huge imposition to be asked.

    As a software developer I'm asked about my ETAs every single day. It's really not that

    • No need to be snarky.

      As a frequent denison of #perl6, the impression I get when this is asked on IRC is the same as what pmichaud finds. Maybe it's not intended that way, but asking is something is 'finished' to me implies 'is the spec completed', not 'is the spec at 6.0', no matter the actual intent.

      Just to add: the folks on #perl6 are very accommodating to new users, including ones that ask that question. It's probably the nicest IRC channel I've been on.

      • I would imagine the people who ask about Perl6's ETA don't care much about the Perl6 spec completion date. It's probably safe to assume they mean when can they do something like `apt-get install perl6`.

        • I would imagine the people who ask about Perl6's ETA don't care much about the Perl6 spec completion date.

          Yes, but the spec and the test suite define what Perl 6 is, not a single implementation. Anything that passes the test suite is considered Perl 6, so Perl 6 can have many implementations. As the article states, having a 'useful Perl 6' will help drive the spec to completion, but it likely won't be the only implementation in the long run.

          It's probably safe to assume they mean when can they do something like `apt-get install perl6`.

          Agreed, and that's the disconnect. It'll probably be something more like 'apt-get install rakudo' or similar.

          • Then why isn't the article called "a useful rakudo"? Why not try and close the "disconnect" rather than perpetuate it?

            Seriously, the Perl6 spec isn't even nailed down yet? What is the hold-up on that? Design by committee?

            Seems like Perl6 might be going the way of GNU/Hurd, eternally under development, and never to land.

            • Then why isn't the article called "a useful rakudo"? Why not try and close the "disconnect" rather than perpetuate it?

              I think b/c it's the only implementation far enough along to get new users interested (and maybe allow them to jump in on other spots NYI).

              Seriously, the Perl6 spec isn't even nailed down yet? What is the hold-up on that? Design by committee?

              Much of the spec is implemented in Rakudo, enough to make it quite 'usable', and Rakudo is passing around 12000 tests. If anything much of the spec has changed due to actual attempts at implementing it, either via Pugs, Rakudo, smop, etc. (the removal of want() comes to mind)

              Again, as mentioned in the article that may be the push needed to flesh out spots in the spec (c

            • I've written a response to this thread in a separate article [perl.org].

              Pm

  • Well, don't wait for user input, just go ahead and finalize sine qua non's like concurrency policy/implementation. Perl6 is already getting lost in the flurry of announcements about new JVM lingos. Something like concurrency support has to be seen as an absolute top priority for any "current" lingo. Perl6 (hopefully) was not conceived of as a nifty-er compiler of digested text reports!

    • That sounds like a design principle guaranteed to make everyone from language designers to implementers to users unhappy with the results.

      What do you want from a concurrency system?

  • I really don't get this argument. It's like, you want a release which you want to advertise to people as ready for consumption, but you don't want to "use up" the 1.0 number delivering something which isn't "finished". Forget the overpromising, it's years too late for that.

    Honestly, no-one will care if the complete Perl 6 is not there, so long as the implementation is good, it's debuggable, you can start making bindings for C libraries easily, and there is an effective module deployment system it should

    • No one cares about “alpha” versions. Look at how much testing even the Perl 5 Release Candidates get: it’s barely distinguishable from none.

      Which is no surprise, and is even less so for alphas. The typical meaning of “alpha” is “we’ve picked a feature set but the features aren’t done yet and we’ve not even started on the bugs” – miles away from production stability.

      That’s not what Rakudo* is about. Quite the opposite: the idea is t

      • And what the heck number are the distribution packagers going to give it?

        It's matching the "Whatever" to the wrong side of the argument. "Rakudo *" to me means the version that a particular person starts using it, not a fixed release.

        Why not just call it 1.0, make it clear to everyone what's finished and what's not, then there is no over-promising.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.