SoylentNews is people
SoylentNews
from the out-with-the-old,-in-with-the-new dept.
Submitted via IRC for TheMightyBuzzard
This morning at The Perl Conference in the Cloud, Sawyer X announced that Perl has a new plan moving forward. Work on Perl 7 is already underway, but it's not going to be a huge change in code or syntax. It's Perl 5 with modern defaults and it sets the stage for bigger changes later. My latest book Preparing for Perl 7 goes into much more detail.
Perl 7.0 is going to be v5.32 but with different, saner, more modern defaults. You won't have to enable most of the things you are already doing because they are enabled for you. The major version jump sets the boundary between how we have been doing things and what we can do in the future.
Remember, Perl was the "Do what I mean" language where the defaults were probably what you wanted to do. In Perl 4 and the early days of Perl 5, that was easy. But, it's been a couple of decades and the world is more complicated now. We kept adding pragmas, but with Perl's commitment to backward compatibility, we can't change the default settings. Now we're back to the old days of C where we have to include lots of boilerplate before we start doing something:
[...]
This is slightly better with v5.12 and later because we get strict for free by using setting a minimum version:
[...]
Perl 7 is a chance to make some of these the default even without specifying the version. Perl 5 still has Perl 5's extreme backward compatibility behavior, but Perl 7 gets modern practice with minimal historical baggage.
Source: https://www.perl.com/article/announcing-perl-7/
(Score: 1, Interesting) by Anonymous Coward on Monday June 29 2020, @04:53PM
There must be some things I misunderstand in their IO subsystem. I took a random 100MB file and this C program (my C is rusty, I just downloaded it and hacked it until it worked):
#include
struct rec { unsigned char x; };
int main() {
int counter; FILE *ptr_myfile; struct rec my_record;
ptr_myfile=fopen("junk.bytes","rb");
for ( counter=1; counter
fread(&my_record,sizeof(struct rec),1,ptr_myfile);
if (counter > 99999990) {
printf("%d\n",my_record.x);
} // end if
}// end loop
fclose(ptr_myfile);
return 0; } // end file
That took 1.06 seconds to run, unoptimized (just "gcc main.c; ./a.out").
This Raku program ran in 0.34 seconds (faster than the C, not a typo):
my $fh = open "junk.bytes", :r, :bin;
my $x = $fh.slurp;
say "Read " ~ $x.bytes ~ ".";
for (1..10) { say $x.pop(); }
That gave the same final bytes as C, but in reverse order (because I'm in a hurry). So Raku can be fast, but some of the IO calls that seem intuitive must be bad/odd ?