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

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/
Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Tuesday September 30, 2008
04:37 PM

Didn't We Use The Phrase "Reverse Sublimation" a While Ago?

[ #37578 ]

The farce that is Perl 6 continues to be little but vapour-ware and really does nothing good for Perl’s image.

admin, Why I'm Writing This Blog

Maybe if I keep saying "We release a new stable version of Parrot on the third Tuesday of every month, and we've done so twenty times now, and every release includes a new stable version of Rakudo, an implementation of Perl 6 on Parrot," people will start getting the message. Perl 6 and Parrot exist and they get better every day. We do all of our development in public. You can see our progress every day.

Goodness gracious, you can even look at Rakudo spectest graphs, updated daily, to see the velocity of progress on Rakudo. I particularly like the sharp uptick in the past week, where we added some 18% more passing tests. The second graph shows this more dramatically.

What the graph doesn't show is that the Google Summer of Code funding ended for Adrian Kreher, that Patrick Michaud has completed the Mozilla Foundation grant, and that Jonathan Worthington (funded for one or two days a week -- I believe it's back to one -- to work on Rakudo) has been on vacation.

Using "vaporware" to describe a project that consistently hits monthly stable releases and increases velocity despite a lack of funding and the vacation of project leaders stretches the definition past the point of belief.

Then again, how many people who "comment" on Perl 6 and Parrot actually bother to look up and quote relevant statistics? (That in itself suggests something about their level of information.)


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Didn't We Use The Phrase "Reverse Sublimation" a While Ago? 25 Comments More | Login | Reply /

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

  • You can say you're working on perl6 all you want, and put out stable parrot releases, but they're not stable releases of "perl 6" until you can go to perl.com and when you click "download" it gives you something other than 5.10.

    *I* know perl6 is progressing, and *you* know perl6 is progressing, and other folks around here know it's progressing, and perhaps it's even usable day-to-day right now, but it's not perceived as "there, we're ready to have regular users use this, and we declare it perl 6.0" until

    --

    :wq!

    • ... they're not stable releases of "perl 6" until you can go to perl.com and when you click "download" it gives you something other than 5.10.

      Fun fact: I edited the Perl.com Downloads [perl.com] page sometime around December 2007 to include information on how to download and build monthly Rakudo releases with the perl6 binary that Jerry and I made work.

      Release-early-release-often is good for development....

      Silly me. I thought it was also good for demonstrating that the software does actually exist -- you know, be

      • include information on how to download and build monthly Rakudo release

        Sure, and right now, it says it's an "in-development" version for "experimentation and testing." Not exactly saying "we're want testers!"

        I'm not saying there isn't progress, I'm saying that people won't treat it as "real" until, as Alias said, people say "here's perl 6.0 alpha 1" and many folks won't really start evaluating it for their own uses until it at least says "beta 1" on the announcements.

        Until then, it just looks like a development in-progress that isn't ready for a wider audience yet.

        I know you

        --

        :wq!

  • It looks like it may be moving forward now, unilke 2001 to around 2005 or so. However, Perl 5 has also adopted Perl 6's useful bits -- "say," "//," named subpatterns, OO stuff (via Moose) -- and via Devel::Declare, may soon get named parameters as well. My wild guess is that Perl 6 will be officially done in 3-5 years. When it's done, Perl 6 will have to compete with a mature Perl 5 that has been consistently cloning many of its best features. Unless Perl 6 has some kind of killer app, that's a very, ve

    • However, Perl 5 has also adopted Perl 6's useful bits.... Unless Perl 6 has some kind of killer app....

      Better internals? Pervasive OO? Mutable lexical grammars? Working exceptions? NCI? Macros? JIT? Bytecode? Grammars? Serializable continuations? Multidispatch? STM? Hyperoperators? Pervasive laziness? Immutable sigils? True reference context? Aliasing and binding? Few globals? A robust parser?

      I can think of two reasons why Perl 5 will never get many of the interesting and useful features

      • Here's my perspective on these things, as someone who uses Perl regularly, and contributes to CPAN but not to the Perl core:

        • Better internals? Not directly relevant to me as a Perl programmer.
        • Pervasive OO? I'm not pervasively OO either, so it doesn't matter.
        • Mutable lexical grammars? Nice.
        • Working exceptions? Perl 5's exceptions work well enough for me.
        • NCI? If it is better than Inline::C.
        • Macros? Nice.
        • JIT? Bytecode? If they reduce the number of times I have to drop down to C for speed.
        • Grammars? Nice.
        • Se

        • It would be great if you were less coy about your two reasons.

          Perl 5's internals are almost unmaintainable. Its internal API has leaked out through XS into the CPAN and the DarkPAN. That's problem one.

          Problem two is that backwards compatibility overrides all other concerns, including problem one. P5P is almost entirely unwilling to consider potentially breaking the DarkPAN, so refactoring poorly designed or badly implemented APIs doesn't happen.

          Most of the features in the list I quoted are impossible w

          • I agree that Perl 5 does move slowly, for the reasons you mention among others, but 5.10 was a big step forward from 5.8, so Perl 5 certainly hasn't ground to a halt. Perl 6 (whichever version) also moves slowly (or at least unevenly), and has much more ground to cover than Perl 5, which has been a mature language for many years. It will be interesting to see whether or not Perl 6 becomes mature before Perl 5 adopts most of its interesting features.

            • Perl 5 certainly hasn't ground to a halt.

              Given multiple years between major releases -- and I'll be charitable and say three and a half years, there's your deprecation cycle length. If you want to remove a misfeature of Perl 5 or its API, you're going to have to wait until April 2012 before you can start using the replacement in production.

              Usually you have to give Oracle, SAP, BEA, or IBM millions of dollars to move software that slowly.

              Don't forget to account for the fact that the "stable" release of Pe

              • Given multiple years between major releases -- and I'll be charitable and say three and a half years, there's your deprecation cycle length.

                Deprecation doesn't matter. If something is deprecated and removed, then if I am using it, some of my code will break (wasting my time), and if I am not, it doesn't matter to me.

                This would make a very boring graph. Plot time on the X axis and the interestingness of the feature adopted on the Y axis and you'll see a flat line that suddenly asymptotes right at the "Hea

        • You only think better internals aren't relevant for you. IF you want bug fixes to perl, you want people to be able to fix bugs without jury rigging.

          You'd probably want bytecode too. I don't hear any Perl programmers seriously saying that they want to recompile everything on every invocation of their script. Want a faster Perl program? Get rid of the compilation step.

          You get the benefit of a lot of things you don't care about.

          • I'm aware of the benefits of these things, but none is a killer feature. Maybe "don't care about" is the wrong phrase -- I just mean that none of them would be a significant factor for me in choosing a language.

            Yes, the complicated internals make bug fixing more difficult. On the other hand, the core code is mature and battle-tested, so it has few bugs, and most of those are in weird corner cases.

            And ahead-of-time compilation, whether to bytecode or native code, has some advantages. But the time only I h

  • Maybe if I keep saying "Nobody is going to try this until you build some easily-downloadable binary packages, stamp it with 'Perl 6 Alpha 1' and release it "officially" someone will eventually release it.

    Christmas would be fairly appropriate though...

    In the same way that adding a "perl6" binary launcher wasn't a big deal technically but had a large effect, unless you specifically build an "outreach" release that DOESN'T rely on people compiling it yourself, nobody is really going to pay attention.

    Practicall

    • Maybe if I keep saying "Nobody is going to try this until you build some easily-downloadable binary packages, stamp it with 'Perl 6 Alpha 1' and release it "officially" someone will eventually release it.

      Are you referring to our Debian packages? Our RPMs? Our Cygwin packages? There are even Windows installers, courtesy of François and Parrot Win32 [sourceforge.net] (generally uploaded the day after a release).

      (As for the Alpha tag, I'd like to think we're sober and practical minded adults who don't succumb to the S

  • Maybe he should have used Perl?

  • ... is a reality check! The way you think people perceive the Perl6 development just isn't the way the world works. Scientifically everything's going well and correct but it will never work with the people you want to persuade that Perl6 is coming along nicely and is a thing to watch. Please stop bashing people for criticizing the Perl6 development, chromatic! I understand that you're putting your heart and soul and a lot of work in it but criticism still is a good thing and in the case of Perl6 it's really

    • A reality check?

      If you (or perladmin or anyone else) want to give the Perl6 devs such a thing, then there are lots of better ways of doing this than commenting the bikeshed colour.

      1) Fix your pet peeve in the source code. Don't like the lack of an install-base on Debian? Make some .deb's and work to get them included in the official Debian repositories. Don't like the lack of contributors? Start recruiting - make people excited about the language.

      2) Start playing with Perl 6 to see if it's really as good as

      • What if I just want to create apps without having to dive into the guts of my favourite language's next version? Not every developer loves poking around at such a low level and I'd like to leave this to the ones who know and love this stuff. I don't think many PHP/Python/Ruby (and Perl) programmers developing popular high-volume web sites participate in developing the next version of their language, do you? What do you think how many construction workers build their own jack hammer? ;-) I didn't mean to dis
        • What souldchild said. I have been trying to follow the development of Perl 6 and, not having a comp-sci background (I'm an engineer), most of it was gobbly gook to me. For instance I have not idea what any of this means:

          Better internals? Pervasive OO? Mutable lexical grammars? Working exceptions? NCI? Macros? JIT? Bytecode? Grammars? Serializable continuations? Multidispatch? STM? Hyperoperators? Pervasive laziness? Immutable sigils? True reference context? Aliasing and binding? Few globals? A robust pars

          • But of course the real question is: if you are not willing to spend the few hours to research what these things are, and how they would benefit your work, why --pray-tell-us-- should anyone be even slightly interested in what you have to say on the matter of Perl6 development?

            [[Side question: do you really not know what "Better internals" means? "A robust parser"? "Macros"? "Working Exceptions"? Hmm...]]

            There's a lot of pushme-pullyou going on in this comment thread: on the one side chromatic wants to push

    • Please stop bashing people for criticizing the [Perl 6] development, chromatic!

      What do you suggest I do with people who haven't done their research and feel the need to bloviate their uninformed opinions all over the Internet on subjects I work on and care about, besides responding with verifiable facts?

      If any of the statistics I posted are wrong, I welcome corrections. If any of the conclusions I've suggested from those statistics are wrong, let's talk about them.

      For anyone to say "Perl 6 does not exist

  • Has Ian Hague's $200,000 [perlfoundation.org] already been used up?

    • Nearly all of it is still available. Several grant applications are in progress. I don't mean to imply that funding is or isn't a constraint at the moment -- only that visible progress has accelerated despite all indications that it should have stalled for a few weeks.

  • There's a simple explanation for the disconnect in user perception of Perl6's status: All of the relevant websites that SHOULD be posting a big giant "DOWNLOAD PERL6 HERE" links are failing to provide such things.

    Going to Rakudo.org gives me... the latest meeting minutes and some links to "other sites", but NOWHERE on the page is a "Here's how you get Rakudo" or even so much as a "What the hell is Rakudo, and why didn't we bother just calling it Perl6?"

    Going to perlfoundation.org/perl6, the download links

    • Ultimately, the reason nobody is using perl6 is because the perl6 guys have done a terrible job of making perl6 easy to obtain.

      That's concrete feedback and fixable. We can work on that. Thank you.

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