Re^2: What's the perl5's future?

> cperl is a recent fork of perl by Reini Urban who is incapable of working with others, so is writing a perl where he can do whatever he likes, unfettered by the difficulties of having to reach consensus.

To the contrary, Reini Urban is not incapable to work with others. He showed that effectively where ever he worked with. It's rather the other way round, and this is what I was critizising. p5p is traditionally incapable to work with others for over 20 years, and everybody who has a bit of an idea how to improve perl5 already left the perl community. There's no one left, and nobody new is coming up. A shark tank of very important wannabes.

That's why perl5 has no future at all with p5p, the porters, acting as maintainers of the language. p5p cannot take technical criticism, cannot lead decision making, and is technically not able to make any proper decisions. That's obvious to everybody outside the p5p echo chamber. Other languages have proper feature management and eventually are successful.

p5p was not able to come up with any language feature. Many of them were spec'ed and outlined 15 years ago with perl6. Many of the new interesting bits, like given/when, which were not implemented by Larry, were implemented by outsiders, not by p5p. And everything p5p did was just horribly wrong and broken, until they had to disable those "experiments". E.g. just recently they disabled lexical topics, instead of simply fixing it. given/when and smartmatch is still broken, because of the sheer nonsense p5p did. They implemented signatures in the most horrible way, even if there exist many good implementations outside core. cperl signatures have 2x more features and are 2x as fast. perl5 signatures are the most prominent exposure of p5p incapabilities, but the lack to be able to maintain the language properly is even more worry some.

In one year cperl already implemented 20 new features from perl6 and has much better security and performance records. cperl has a goal, perl5 has none. And cperl doesn't have to deal with the problematic people inside p5p. (dave_m is not problematic btw, he just doesn't see that much light)

Only with cperl features and bugfixes are discussed publicly and smoked before being merged to master. In perl5 many changes were made just because one committer thought he liked it, and thereby broke everything around him. And of course those mistakes were never reverted.

cperl is effective continuation of the perl5 implementation efforts from the day when Larry left p5p, perl5 is the stagnation thereof. bug reports are ignored, feature and implementation discussions are hampered by p5p's incapabilities. Decisions are based on friendship and personal connections, but not based on any technical merits. The top 5 implementors are effectively dead wood who produce only nonsense and do more harm than good. This is going on for 20 years, and the code base is an unmaintainable battlefield. And in total violation of their new CoC guidelines p5p is constantly violating those, calling their users and critics assholes without any visible outcry. And the one who is critizising those abuses is called the abuser.

At least they can analyze bugs and sweet talk their achievements.

Comment on Re^2: What's the perl5's future?

Replies are listed 'Best First'.
Re^3: What's the perl5's future? by marioroy (Prior) on Sep 19, 2016 at 01:56 UTC
Update: For the example script, there is no noticeable difference when comparing Perl v5.20+ against cperl v5.22+. I had compared Perl installed on the OS; Perl 5.18.2 (Mac OS X 10.11.6) and Perl 5.16.3 (CentOS 7.2) against cperl 5.22c. Thank you dave_the_m for catching this. Thank you for cperl, rurban. I entered a demonstration running 25% to 33% faster with cperl depending on the platform. Re^3: use threads for dir tree walking really hurts Furthermore, the optional modules for MCE and MCE::Shared work without a glitch. Unless PDL is present, MCE and MCE::Shared will use Sereal 3.008 or later for serialization if available on the system. Storable is used otherwise. The IO::FDPass module is beneficial for passing file descriptors to the shared manager process. This applies to MCE::Shared::Condvar, MCE::Shared::Handle, and MCE::Shared::Queue. `1. Canary-Stability-2011 (required by IO::FDPass) 2. IO-FDPass-1.1 (optional, used automatically by MCE::Shared) 3. Sereal-Decoder-3.015 (optional, used by MCE and MCE::Shared) 4. Sereal-Encoder-3.015 (optional, ditto) 5. Sereal-3.015 (optional, ditto) 6. MCE-1.805 7. MCE-Shared-1.804 (add-on module for MCE)` [download] The modules listed above work flawlessly with perl11/cperl Github branches maint-5.22c and maint-5.24c. Threads is not required to run MCE or MCE::Shared. I built cperl with threads support and that works too. `./Configure -Dprefix=/opt/cperl-5.22c -sder -Dusethreads -Dusecperl -A +ccflags=-msse4.2 ./Configure -Dprefix=/opt/cperl-5.24c -sder -Dusethreads -Dusecperl -A +ccflags=-msse4.2` [download] Thank you for making Perl run faster. Warm regards, Mario.	[reply] [d/l] [select]
Re^4: What's the perl5's future? by dave_the_m (Monsignor) on Sep 19, 2016 at 08:04 UTC
I entered a demonstration running 25% to 33% faster with cperl I see no such performance difference when comparing bleadperl with the current cperl git head. Running `perf stat -r 30`, I get the following results: `perl-5.24.0 6101.313876 task-clock (msec) 18,547,679,958 cycles bleadperl, v5.25.4-176-g23e15e7 6027.767495 task-clock (msec) 18,321,742,652 cycles cperl, v5.23.0-3278-gdff4721 6046.706723 task-clock (msec) 18,380,297,957 cycles` [download] All the above were built with `-des -Duseithreads -Accflags=-msse4.2` and with all the modules you listed installed, and were run against the script shown in your link, on a directory hierarchy containing 250932 files. Dave.	[reply] [d/l] [select]
Re^5: What's the perl5's future? by Your Mother (Archbishop) on Sep 19, 2016 at 14:08 UTC
And I want to say thank you, dave_the_m, for maintaining some cool and objectivity. I honestly wasn't sure what to think after reading—Re^2: What's the perl5's future?—since I enjoy a good rant and the guilty pleasure of indignation by proxy. Then I went and read the email threads' backstory. o_O I would leave or cut down on participation if I had to work with that kind of pointless, unproductive, toxic flagellation. I'm grateful you didn't do so.	[reply]
Re^5: What's the perl5's future? by marioroy (Prior) on Sep 19, 2016 at 11:24 UTC
Thank you dave_the_m. For the example script, the performance difference is seen with Perl 5.20+ versus the OS installed Perl 5.18.2 on Mac OS X 10.11.6 and Perl 5.16.3 on CentOS 7.2. I thought the performance increase was due to cperl 5.22c. I tried Perl 5.20 and Perl 5.22. Both run as fast as cperl. Hurray for Perl 5.20 and later releases.	[reply]
Re^3: What's the perl5's future? by dave_the_m (Monsignor) on Sep 18, 2016 at 19:22 UTC
To the contrary, Reini Urban is not incapable to work with others That would explain why hordes of programmers have flocked to contribute to cperl. Oh wait, no they haven't. Dave.	[reply]
Re^4: What's the perl5's future? by Anonymous Monk on Sep 18, 2016 at 19:46 UTC
That would explain why hordes of programmers have flocked to contribute to cperl. Oh wait, no they haven't. Ah, the important part of the message, labeling people because you're mad at their technical points It doesn't take much to prove you wrong, see for yourself https://github.com/perl11, there is more than one "People" on the project	[reply]
Re^5: What's the perl5's future? by dave_the_m (Monsignor) on Sep 18, 2016 at 21:00 UTC
Ah, the important part of the message, labeling people because you're mad at their technical points No, I pointed out that the thesis that p5p was driving away contributors, and that they would therefore gather around cperl, was incorrect. There was no labelling in that statement, nor any demonstration that I'm mad at anyone's technical points. it doesn't take much to prove you wrong, see for yourself https://github.com/perl11, there is more than one "People" on the project https://github.com/perl11/cperl/network/members shows a total of 4 members. And almost all the commits to cperl are authored by you. It's still essentially your personal project. But I'm not going to argue further with you; I explained in this thread from a year ago why it was pointless engaging you in further debate. Good bye Dave.	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.