Re: What's the perl5's future?

I have been a perl5 maintainer for about 14 years, so I can speak of this with some knowledge.

The blog entry you quote is by Marc Lehmann, a deeply unpleasant individual (at least judging by his on-line persona). He writes XS modules that make heavy use of perl core internals, often undocumented internals. When we make a change to the internals (e.g. to fix a bug or improve performance) it will sometimes break his code. Rather than working with us to resolve the issue (sometimes a module might need fixing, sometimes we might need to back out the change), he just lashes out, accusing us of having no respect for backwards compatibility, usually in highly inflammatory terms.

One irony is that these breakages are usually spotted first by us and reported to Marc. We run a system whereby the current development branch of perl is continually run against thousands of CPAN modules, and if any break, it is reported to the p5p list, along with a bisect of which commit broke it. We then look carefully, decide whether perl needs fixing or the module, and proceed accordingly. This is because we care about backwards compatibility so much.

As far as I'm aware, there are people currently working to make Marc's modules work under 5.22. Whether Marc will accept that work, I don't know.

AFAIKT, stableperl isn't intended to be an ongoing fork of perl; its simply a snapshot of 5.22 created by Marc with whatever commits broke his code removed.

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.

Rperl is a module run within perl that allows you to write chunks of code in a toy subset of perl that go much faster; so it isn't a fork or rival to perl.

Dave.

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

Replies are listed 'Best First'.
Re^2: What's the perl5's future? by xiaoyafeng (Deacon) on Oct 12, 2015 at 10:36 UTC
Thanks, I'm often out of p5p circle, but I think the root reason to cause this is because age of perl5. What's the next of perl5? just bug-fix, optimization? do the p5p guys consider add new features to perl5? I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction	[reply]
Re^3: What's the perl5's future? by Discipulus (Canon) on Oct 12, 2015 at 10:42 UTC
Oh they added a lot of things! you can profit the read of a related thread: Should I come back to Perl? where you can find very good perpectives on the matter. L* There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.	[reply] [d/l]
Re^2: What's the perl5's future? by rurban (Scribe) on Sep 18, 2016 at 18:56 UTC
> 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.	[reply]
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
Re^5: What's the perl5's future? by marioroy (Prior) on Sep 19, 2016 at 11:24 UTC
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
A reply falls below the community's threshold of quality. You may see it by logging in.