in reply to Re: Reasons for Using "Perl6" (don't need to earn a living?)
in thread Reasons for Using Perl 6

As far as I know, there are no groups or organizations that have adopted "Perl6" other than hobbyist clubs.
I guess that's probably correct, although the term "hobbyist clubs" seems a bit deragotary here.
It is not a production-ready language ...
Pure prejudiced opinion, at variance with facts
... still breaks backwards compatibility with new releases,
I do not know such case (except for very minor fixes or adaptation to new Unicode standards), perhaps you can enlighten us.
... has a dearth of library extensions for doing real work
Well I agree that the P6 ecosystem is not as rich and as mature as the P5 CPAN, but there are many hundreds of modules for almost everything useful. See https://modules.perl6.org/. And you can use most P5 modules in Perl 6, as well as Python, C and Java libraries (much more easily than it would be in P5).
... and is orders of magnitude slower than using Perl for the things it can do...
You should update your information, that may have been true 3 or 4 years ago, but that's no longer true. P6 might still be slightly slower than P5 for quite a few things (and may be faster for others), but it's certainly not "orders of magnitude" behind in terms of speed.
but it really doesn't have much to do with Perl
Not true. These two languages are different programming languages, but they are very close to each other, like brothers and sisters.

On the issue of the similar names, well, yes, perhaps, it may be unfortunate, things evolved in an unpredicted way. I am afraid it will probably be difficult to change it now.

To the OP: for the sake of full disclosure, I am the author of one of the Perl 6 books, so I may have my own prejudices. But 1nickt has been known here as a regular staunch opponent to P6, and may have his own. But I guess you discovered by yourself that we disagree on that.

Update: fixed a couple of minor typos.

  • Comment on Re^2: Reasons for Using "Perl6" (don't need to earn a living?)

Replies are listed 'Best First'.
Re^3: Reasons for Using "Perl6" (don't need to earn a living?)
by Arunbear (Prior) on Dec 23, 2017 at 21:56 UTC
    Could you say more about the facts of it being production-ready?

    You acknowledged the ecosystem issue. But isn't that a major part of production-readiness? I just had a look around modules.perl6.org, but it seems not quite CPAN like e.g clicking on any of the modules there takes you to various github pages, so the documentation and other benefits of CPAN aren't there. Is there a plan for it to be more like CPAN?

[reply]
      Yes, I agree with you, Arunbear, the ecosystem is a major part of production readiness. And I said that the P6 ecosystem is not as rich and mature as its Perl 5 counterpart, but that does not mean that it is inexistent, far from that. As I said, there are several hundred modules out there. You have a module installer (it's callef zef, it used to be Panda, but Panda has been replaced with zef a few months ago), which, as far as I tell, works flawlessly. And you have modules which make it possible to run Perl 5 modules (so almost the whole CPAN), as well as C, C++, Python and Java libraries.

      I am not quite sure about all the details at this point, but it is now possible to upload Perl 6 modules to the CPAN. I suppose the existing modules will be moved to the CPAN with time.

[reply]
[d/l]
[reply]
Re^3: Reasons for Using "Perl6" (don't need to earn a living?)
by Jenda (Abbot) on Dec 23, 2017 at 03:24 UTC

    If it were production-ready, some team would adopt it for production work. If you consider "there are no groups or organizations that have adopted "Perl6" other than hobbyist clubs" probably correct then you'd probably agree it's not seen as production-ready. Or even close enough to production-ready to start a longer project in hope it's going to get production-ready in time for the project to go to production.

    I've seen several "all behold, I've made Perl 6 quicker" posts here on Perlmonks and while the message to stand in awe of claimed to have made Perl6 several times quicker, it was still at least two magnitudes slower than a matching Perl 5 solution.

    Those two languages are different programming languages, but I would not consider them just siblings. They are more like a person and his atomic-waste-mutated brother with several extra limbs at weird places, odd number of eyes and many extra organs that nobody knows the purpose of.

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.

[reply]
      Yes, Perl 6 is generally slower than Perl 5, this has not been denied by any one. But very significant improvements have been made and more are to come.

      Two orders of magnitude? This is a factor of 100. So you're saying that Perl 6 is at least 100 times slower. Let's see.

      This is a very simple benchmark on a loop: 

      C:\Users\Laurent>perl -E "my $c = 1; my $start = time; while (1) { $c+
++; last if (2 * $c ) > 50000000 ; }; say time - $start; say $c"
4
25000001

C:\Users\Laurent>perl6 -e "my $c = 1; my $start = time; while (1) { $c
+++; last if (2 * $c ) > 50000000 ; }; say time - $start; say $c"
21
25000001

C:\Users\Laurent>perl6 -e "my int $c = 1; my $start = time; while (1) 
+{ $c++; last if (2 * $c ) > 50000000 ; }; say time - $start; say $c"
9
25000001

      [download]
      So here, the first Perl 6 test took 21 seconds, which is a bit more than 5 times slower than Perl 5. That's not anywhere near two orders of magnitude. Just adding the int hint (no pun intended) for the compiler to optimize its handling of the integer variable led to 9 seconds, so that, in the last test, Perl 6 is about 2.25 slower than Perl 5. I wish it were not so, but that's where we stand. There is definitely room for improvement. A year ago, or so, it might have been slower by a factor of 10. What will it be in a year from now? I really don't know, but performance improvements are being made almost every single week, so it is likely to improve significantly.

      And, BTW, I know the results are low resolution, but that's not a Perl 6 limitation: Perl 6 has a built-in now function giving a much higher resolution: 

      C:\Users\Laurent>perl6 -e "my int $c = 1; my $start = now; while (1) {
+ $c++; last if (2 * $c ) > 50000000 ; }; say now - $start; say $c"
8.9252329
25000001

      [download]
      For some other computations, Perl 6 will slower than Perl 5 by a significantly higher margin, perhaps 10 to 20 times, but, again, it is improving all the time.

      Also, look at the Perl 5 and Perl 6 pieces of code: can anyone say that these languages are not closely related?

[reply]
[d/l]
[select]
Re^3: Reasons for Using "Perl6" (don't need to earn a living?)
by 1nickt (Canon) on Dec 22, 2017 at 21:24 UTC

    Hi esteemed Brother Laurent_R, I don't care to get into a point by point debate with you. I will say only that I base my statements on what I have read with my own eyes in the last 6 - 8 months.

    • Tux announces 10% speed boost in P6 CSV handling, bringing P6 to less than 350 times slower than Perl: August 2017
    • "Zoffix", TPF-funded P6 developer and cheerleader, states: "Tiny ecosystem full of abandoned modules; Slow; Buggy ;Some stuff still gets changed around, so you may need to tweak your code to work on latest-and-greatest version once in a while; No mature modules for common tasks; your options are to roll your own, use works in progress, or use Perl 5's modules via Inline::Perl5 and pray it works." on Reddit, May 2017
    • Official notice of breaking changes on "Perl6" website, April 2017
    • perl.org has had a design change since the summer so I can no longer find the quote but until recently P6 was described there as not production-ready. I've noted it in various posts on the topic. The language on perl.org sites now emphasizes that Perl and P6 are not compatible.

    As I have stated before, I am not an opponent to "Perl6" - my problem is with the hijacking of the name, versioning number, reputation, community and funding of Perl to promote a new experiment. As long as the P6 proponents use that confusion to promote their agenda, I'll continue clarifying to promote mine: the health and longevity of Perl.


    The way forward always starts with a minimal test.
[reply]

      My speed tests compare different aspects of the languages, but focus on how close pure perl6 can get to perl5 + XS. As perl6 has no XS, that is not really a fair compare, but it aims on getting a general idea of how the perl 6 language itself optimizes performance over time.

      Comparing pure perl5 (0.676) to pure perl6 (2.596) shows a factor of 3.8 *today* (2018-01-02). A comparison to perl 5 + XS shows a factor of 130, which is *much* closer than the 350 from August, and that is speed improvement in the language itself. If a process is to be written purely for speed, that might be a consideration to stick to perl 5. If your process however only parses a few thousand lines en development of the program itself is more important that an extra second in parsing the CSV (most processes parse CSV as part of a bigger picture), than reconsidering a look at perl 6 might surprise you. It is quite stable by now.

      I also compare the same test to other languages on a daily basis.

      One speed improvement in perl 6 that has been really noticable is in the area of parallelization. Something that my tests do not show, as one cannot parse CSV data from a single stream in parallel.


      Enjoy, Have FUN! H.Merijn
[reply]
        A comparison to perl 5 + XS shows a factor of 130, which is *much* closer that the 350 from August, and that is speed improvement in the language itself.

        In theory, Rakudo is a language with a better type system than C. In theory, Rakudo has a JIT and shouldn't require you to write XS or C or internals code to optimize things. In theory, a better optimized system wouldn't have to cross the language/ABI/calling conventions boundary of Perl/XS.

        In theory, Rakudo was designed to be easier to optimize (and to require fewer pessimizations) than Perl.

        Now I know as well as anyone that optimizations are difficult and time consuming and need a lot of careful thought and tuning, but parsing and file I/O aren't exotic operations that tax your ability to think of complicated optimization strategies. Rakudo/Moar still being over two orders of magnitude slower than optimized Perl for CSV parsing is not, to me, a ringing endorsement.

[reply]
      Hi dear 1nickt,

      first I should say that I very much respect you and your opinions, even when I don't agree with some of them. You're one of the (very few) monks whose posts I have donwvoted a few times, but I have upvoted your posts much more often, as I value very much your contributions to this site in general. So, despite our serious disagreement on P6, I usually love your contributions to Perl and very often upvote them. And I am pretty sure that, if we were living in the same area, I would enjoy having a beer with you (and I think you would enjoy it too).

      I am not really interested in getting into a detailed debate on P6 with you, it would go nowhere. Just one point that any monk can witness: your Zoffix"'s quote is just unfair: Zoffix tried to make a fair comparison between P5 and P6, with pros and cons for each, and you just cherry picked those comments that fit your view point. That's not how I would do it, to say the least.

[reply]

In Section Seekers of Perl Wisdom