Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^3: Reasons for Using "Perl6" (don't need to earn a living?)

by 1nickt (Monsignor)
on Dec 22, 2017 at 21:24 UTC ( #1206074=note: print w/replies, xml ) Need Help??


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

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.
  • Comment on Re^3: Reasons for Using "Perl6" (don't need to earn a living?)

Replies are listed 'Best First'.
Re^4: Reasons for Using "Perl6" (don't need to earn a living?)
by Tux (Abbot) on Jan 02, 2018 at 11:27 UTC

    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
      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.

Re^4: Reasons for Using "Perl6" (don't need to earn a living?)
by Laurent_R (Canon) on Dec 22, 2017 at 22:37 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1206074]
help
Chatterbox?
NodeReaper serves mincemeat tarts with the cider

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2018-07-17 23:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?















    Results (379 votes). Check out past polls.

    Notices?