4 ms·

Reini, aren't you the sole dev working on cperl, the fork you set up because you disagreed with some of the patchs perl-porters accepted/rejected?

rurban 9y ago
A single +1 developer is better than -5 developers. cperl got 10x more done in 2 years than p5p in 15 years, and the 10x factor is ongoing. In a few years nobody will use perl5 anymore, everybody will use cperl instead. I didn't only disagree with some patches, I disagree with most of the feature decisions, management and bugfix handling. And esp. with their negative track record. perl5 deserves a properly managed project and the perl6 features, so I did it. At an important time, with :const, types and signatures upcoming. And perl5 should not be used in public services due to its lack of security (I am warning against it since 5.16), not talking about the feature mishandling. See the perl11 blog. Some numbers: In the last 2 years, p5p produced 12005 commits (2 releases), whilst I produced 6291 commits. That's >30%. The 2nd most prolific author did 3104 (unicode), the third 1689. And I squash commits into features and bugfixes and don't spread it out over 3-5 postfixes, because cperl works in branches, not posting directly to master. Of those 6291 commits you have nothing in perl5, but they continue to play stupid and take nothing. Features wise and security fixes it's more like 1000%, not 30%.
- topkeker 9y ago
  Reini, more importantly, do you like memes?
- throwaway7645 9y ago
  Looks like a good job.
- petre 9y ago
  Rieni, what happened to perl11 and p2 on potion? It looked like a very interesting project.
  - rurban 9y ago
    p2 was too much work to come up with a backcompat p5 library with all its problems. And I saw no easy way to add multithreading. Forking perl5 was easier in the short run. In the long run switching out to a fast VM for tight loops like p2, rperl or spvm (formerly called sperl) is still being considered. Perl6 inline::perl5 is unfortunately not doing too good, and I see no way forward with their architecture. perl11 is doing very well. Many perl6 features are already in cperl, many more not yet completed. The design is done and sound.
- yellowapple 9y ago
  "In a few years nobody will use perl5 anymore, everybody will use cperl instead." That seems like an awfully bold claim. cperl is great, don't get me wrong, but if I'm going to move away from Perl 5 to a different Perl I'd rather just move to Perl 6 (and, in fact, I already have for some of my latest pet projects; so far, I've been very impressed).
  - rurban 9y ago
    Perl 6 is a different language, no chance for a replacement. It's also much slower and unusable for professional usage. cperl is a not a different perl, it's a perl5 replacement, which is faster, more secure, less bugs and more features. types and using a modern perl is optional. 90% of the vm and toolchain is unmaintained by p5p, and taken over by cperl.
    - yellowapple 9y ago
      "It's also much slower" Perl was never intended to be fast for computers. It was intended to be fast for programmers. Perl 6 does a pretty darn good job of that, and additionally already has working and easy-to-use C/C++-compatible FFI that I can use today to offload things that really do require maximum computational performance (that latter point wasn't true for cperl last I checked; "extern sub ..." is still a "todo" item AFAICT, and I don't really see an equivalent to Perl 6's "is repr(CPointer)"). "and unusable for professional usage." By what measure? More importantly, by what measure in which cperl fares any better? "more features" Not at all the impression I'm getting from perl11.org/cperl in relation to Perl 6. What you're saying is certainly true in relation to Perl 5, though.
      - rurban 9y ago
        extern sub is actively being worked on. The technical problem is not the ffi, this is trivial, but to fix the broken attributes architecture beforehand. They are not usable at runtime (variable arguments) and Attribute::Handlers only makes it worse. Of course cperl is lacking compared to perl6 features, user facing. Because I had to fight first p5p sloth, like broken designs for everything. cow, const, threads, attributes, regex, scalar, arrays, hashes, functions, types, lecical $_, objects, symbols, unicode, build system, warnings, exceptions, the VM, ... http://perl11.org/blog/p5p-incompetence.html http://perl11.org/blog/p5p-incompetence.html is a short overview of the technical problems to be fixed. Professional use: read cperlpod cperl. No security process and competence, lack of progress, lack of maintainance of critical modules (cpan is fine, p5p and toolchain authors are the problem), no types, no compiler, recommending worst practices to move towards Java, no technical management, just community leaders without any idea what they are deciding, loosing all competent devs in the last decades and with just the remaining dead wood vocally protecting their turf, with the usual racial and more unpleasant slurs of the leadership towards its users and co-devs. As company you wouldn't want to be associated with them, but their counter propaganda silencing and censoring the critics works well.

rurban 9y ago

A single +1 developer is better than -5 developers. cperl got 10x more done in 2 years than p5p in 15 years, and the 10x factor is ongoing. In a few years nobody will use perl5 anymore, everybody will use cperl instead. I didn't only disagree with some patches, I disagree with most of the feature decisions, management and bugfix handling. And esp. with their negative track record. perl5 deserves a properly managed project and the perl6 features, so I did it. At an important time, with :const, types and signatures upcoming. And perl5 should not be used in public services due to its lack of security (I am warning against it since 5.16), not talking about the feature mishandling. See the perl11 blog. Some numbers: In the last 2 years, p5p produced 12005 commits (2 releases), whilst I produced 6291 commits. That's >30%. The 2nd most prolific author did 3104 (unicode), the third 1689. And I squash commits into features and bugfixes and don't spread it out over 3-5 postfixes, because cperl works in branches, not posting directly to master. Of those 6291 commits you have nothing in perl5, but they continue to play stupid and take nothing. Features wise and security fixes it's more like 1000%, not 30%.

topkeker 9y ago
Reini, more importantly, do you like memes?
throwaway7645 9y ago
Looks like a good job.
petre 9y ago
Rieni, what happened to perl11 and p2 on potion? It looked like a very interesting project.
- rurban 9y ago
  p2 was too much work to come up with a backcompat p5 library with all its problems. And I saw no easy way to add multithreading. Forking perl5 was easier in the short run. In the long run switching out to a fast VM for tight loops like p2, rperl or spvm (formerly called sperl) is still being considered. Perl6 inline::perl5 is unfortunately not doing too good, and I see no way forward with their architecture. perl11 is doing very well. Many perl6 features are already in cperl, many more not yet completed. The design is done and sound.
yellowapple 9y ago
"In a few years nobody will use perl5 anymore, everybody will use cperl instead." That seems like an awfully bold claim. cperl is great, don't get me wrong, but if I'm going to move away from Perl 5 to a different Perl I'd rather just move to Perl 6 (and, in fact, I already have for some of my latest pet projects; so far, I've been very impressed).
- rurban 9y ago
  Perl 6 is a different language, no chance for a replacement. It's also much slower and unusable for professional usage. cperl is a not a different perl, it's a perl5 replacement, which is faster, more secure, less bugs and more features. types and using a modern perl is optional. 90% of the vm and toolchain is unmaintained by p5p, and taken over by cperl.
  - yellowapple 9y ago
    "It's also much slower" Perl was never intended to be fast for computers. It was intended to be fast for programmers. Perl 6 does a pretty darn good job of that, and additionally already has working and easy-to-use C/C++-compatible FFI that I can use today to offload things that really do require maximum computational performance (that latter point wasn't true for cperl last I checked; "extern sub ..." is still a "todo" item AFAICT, and I don't really see an equivalent to Perl 6's "is repr(CPointer)"). "and unusable for professional usage." By what measure? More importantly, by what measure in which cperl fares any better? "more features" Not at all the impression I'm getting from perl11.org/cperl in relation to Perl 6. What you're saying is certainly true in relation to Perl 5, though.
    - rurban 9y ago
      extern sub is actively being worked on. The technical problem is not the ffi, this is trivial, but to fix the broken attributes architecture beforehand. They are not usable at runtime (variable arguments) and Attribute::Handlers only makes it worse. Of course cperl is lacking compared to perl6 features, user facing. Because I had to fight first p5p sloth, like broken designs for everything. cow, const, threads, attributes, regex, scalar, arrays, hashes, functions, types, lecical $_, objects, symbols, unicode, build system, warnings, exceptions, the VM, ... http://perl11.org/blog/p5p-incompetence.html http://perl11.org/blog/p5p-incompetence.html is a short overview of the technical problems to be fixed. Professional use: read cperlpod cperl. No security process and competence, lack of progress, lack of maintainance of critical modules (cpan is fine, p5p and toolchain authors are the problem), no types, no compiler, recommending worst practices to move towards Java, no technical management, just community leaders without any idea what they are deciding, loosing all competent devs in the last decades and with just the remaining dead wood vocally protecting their turf, with the usual racial and more unpleasant slurs of the leadership towards its users and co-devs. As company you wouldn't want to be associated with them, but their counter propaganda silencing and censoring the critics works well.