Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday June 29 2020, @08:43AM   Printer-friendly
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/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by Anonymous Coward on Monday June 29 2020, @11:08AM (23 children)

    by Anonymous Coward on Monday June 29 2020, @11:08AM (#1014013)

    I would add that Perl6/Raku has been out for 4.5 years, and it's spectacular. Performance was terrible with the initial release, but now it's within 2x of other scripting languages in most cases and ahead in a few, and more optimizations are in development. You get much simpler and more consistent syntax than Perl5 (or 7), full OO with multiple inheritance and a full meta-object protocol, function signatures with named and default arguments, optional static type checking (and it is enforced), multi-methods, operator overloading, optional generics, adjustments to the regular expression syntax to improve readability, async/await, promises, and other concurrency primitives, enums, guards on function parameters, and a built in grammar system to simplify writing all kinds of Deals. A macro system also exists but is being rewritten.

    Raku covers all of the territory from "improved Perl" through Python, Ruby, Java, C#, and most of Scala or even Haskell.

    Starting Score:    0  points
    Moderation   +3  
       Interesting=2, Underrated=1, Total=3
    Extra 'Interesting' Modifier   0  

    Total Score:   3  
  • (Score: 2, Disagree) by The Mighty Buzzard on Monday June 29 2020, @01:27PM (16 children)

    Dude, if you want Python just use Python. There are plenty of us who know why Perl is way, way more useful for specific tasks. Perl6 staying in the formal release chain would have killed that utility.

    --
    My rights don't end where your fear begins.
    • (Score: 0) by Anonymous Coward on Monday June 29 2020, @01:42PM (2 children)

      by Anonymous Coward on Monday June 29 2020, @01:42PM (#1014063)

      "Dude, if you want Python just use Python"

      There are many many programming patterns that work in other languages that don't work in Python. Python is mostly useful because it is trivial to export C++ API's into Python. If it was even remotely near as easy in Perl, there would be no Python.

      For the previous post, thanks, I will take a look at Raku. My issue is whether I can use a toolchain to make clean C++ API extensions in an interpreted language. This is the number one reason for using Python. It isn't faster or cleaner or easier to debug as most people claim because it requires way more orthoganality. So the #1 issue for me is: Can I take a C++ API, run a simple toolchain and make an interpreted language API.

      In my experience that is the only practical reason to use Python over another language.

    • (Score: 1, Insightful) by Anonymous Coward on Monday June 29 2020, @02:54PM (9 children)

      by Anonymous Coward on Monday June 29 2020, @02:54PM (#1014097)

      I like Perl, I like Python, and Raku blows them both to hell. As I said, it covers all of the territory occupied by Perl, Python, C#, and Java and most of the territory occupied by Scala and Haskell. The only place Raku isn't prepared to compete is maximum performance computing - C, C++, Fortran, ATS, (maybe) Rust. Even then, the Raku syntax for FFI is much easier to work with than XS.

      The Perl6 name was a mistake, because nearly zero Perl5 code will run unmodified in Raku. It's a different language, and both Perl and Raku would have benefitted immensely if they had the foresight to label it that way from the beginning. But Larry Wall and co knocked this one out of the park.

      • (Score: 2) by The Mighty Buzzard on Monday June 29 2020, @09:07PM (8 children)

        Raku isn't compared to compete in the place Perl is most useful: arbitrary text mangling, quickly coded.

        --
        My rights don't end where your fear begins.
        • (Score: 0) by Anonymous Coward on Tuesday June 30 2020, @12:32AM (7 children)

          by Anonymous Coward on Tuesday June 30 2020, @12:32AM (#1014319)

          ?? Perl has the amazing and significant advantage of much faster startup and lower overhead than Raku, and the even more significant advantage that it's rare to find a *Nix installation without it. And those are completely valid reasons to use Perl over Raku for a task.

          But did you really think Larry Wall was going to try to make a language in the Perl family and kick text wrangling to the curb? That would be like having Guy Fieri and Mario Batali announce that they were going to collaborate on a new nail salon. Raku is excellent for text wrangling.

    • (Score: 2) by VLM on Monday June 29 2020, @06:24PM (2 children)

      by VLM (445) Subscriber Badge on Monday June 29 2020, @06:24PM (#1014194)

      If I don't care about performance I already use Ruby. Raku is pretty much "NIH version of Ruby".

      Honestly I have severe problems using Raku and Ruby because the syntax is practically the same but not quite.

      Quick trivia question to demonstrate the agony, which is proper Ruby syntax and which is proper Raku syntax? I just can't program in both languages without trying to write Ruby in Raku and Raku in Ruby, and there's more cool stuff out there for Ruby, so ...

      bigassArray[5..10].join(',')

      @bigassArray[5..10].join(',')

      I like Perl and I like that Perl 7 is something like "lets take the modern perl book and shrink it from a book to a page".

      I have a nifty book named "Modern C" which is unfortunately long as hell list of things not to do. There are languages where the "modern wtfLang" book would be a couple pages long at most. Clojure I guess.

      • (Score: 2) by maxwell demon on Tuesday June 30 2020, @12:48PM

        by maxwell demon (1608) on Tuesday June 30 2020, @12:48PM (#1014469) Journal

        I've never programmed in either Perl 6/Raku or Ruby, but the trivia answer is easy. The second one is the Perl6 version, as it has the Perl-typical "@" for arrays.

        --
        The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 0) by Anonymous Coward on Tuesday June 30 2020, @06:06PM

        by Anonymous Coward on Tuesday June 30 2020, @06:06PM (#1014609)

        Obviously Ruby has a > 100x advantage when it comes to the list of available software already written in it, and it's a good language.

        If I was just working on something because I needed to get it done for a job, or even a project a friend asked for help on, or some annoyance, I would pick the language that offered the quickest path to a maintainable solution. I pick Raku when I'm coding for fun. I would love for it to reach the point where it is the first tool I reach for to solve problems quickly and maintainably, but for now it's just my favorite toy.

  • (Score: 3, Interesting) by bzipitidoo on Monday June 29 2020, @01:33PM (5 children)

    by bzipitidoo (4388) on Monday June 29 2020, @01:33PM (#1014056) Journal

    When I last tried Perl 6, some 3 years ago, it was dog slow. Just to read in a 100M file, one byte at a time, took 20 minutes. Same program in C took 2 seconds. Good to hear that they've optimized. Wonder how fast it could read 100M now?

    I saw the Perl 6 -> Raku name change a few months ago. The fact that they're rolling out Perl 7 for the new name, rather than Perl 6, suggests that the renaming to Raku will never totally stick.

    • (Score: 1, Interesting) by Anonymous Coward on Monday June 29 2020, @03:59PM

      by Anonymous Coward on Monday June 29 2020, @03:59PM (#1014125)

      I think the jump to Perl 7 is so that if someone did a web search for "Perl 6 do X" they don't get code snippets from Raku instead of for Perl 6.

      I just tested file IO and you're correct, it is horrifically slow. Small files are fine - I have a web media server written in Raku running right now without issues. But reading a 100MB file from a spinning platter drive took almost 10 minutes and used many GB (?) of memory. There are features you can use to improve speed and reduce memory usage, but the defaults shouldn't be this wildly bad. Thanks for mentioning it, I'm going to open a Github issue.

    • (Score: 1, Interesting) by Anonymous Coward on Monday June 29 2020, @04:53PM

      by Anonymous Coward on Monday June 29 2020, @04:53PM (#1014154)

      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 ?

    • (Score: 0) by Anonymous Coward on Monday June 29 2020, @06:57PM (2 children)

      by Anonymous Coward on Monday June 29 2020, @06:57PM (#1014211)

      Okay, I've done more testing because you got me interested. Short summary: unbuffered IO is dreadfully slow, buffered IO is adequately fast but still not as fast as other scripting languages.

      I took a 100 million byte binary file and then wrote six programs to traverse the file and print the last few bytes. Raku 2020.06 single byte read: almost 14 minutes. Raku 2020.06 read in 64k buffered chunks: 0.35 seconds (Raku 'Hello World is 0.22 seconds.), and Raku on my machine has a 0.22 seconds tartup time. C single byte read: 1.04 seconds. C read in 64k buffered chunks: 0.021 seconds. Python single byte read: 17 seconds. Python read in 64k buffered chunks: 0.06 seconds (Python 'Hello World' is 0.01 seconds.).

      So with 64k buffered reads, Raku is 6 times slower than C and 3 times slower than Python (if you ignore the startup overhead). With the single byte (unbuffered) reads, Raku is around 750 times slower than C and 50 times slower than Python. Damn.

      • (Score: 2) by bzipitidoo on Monday June 29 2020, @09:46PM (1 child)

        by bzipitidoo (4388) on Monday June 29 2020, @09:46PM (#1014267) Journal

        I expect one reason the C program is so fast is that, under the hood, the C stdio library really is buffering the file read even when the program is reading only one byte at a time. Evidently, Raku is not.

        I guess it comes down to whether an app programmer should have to worry about I/O buffering, or not. And the way programming has evolved over the years, with the pushing of everything that can be pushed off to the computer, such as memory management (smart pointers) and hashing, then, absolutely yes, buffering for fast I/O should be the system's problem, not the programmer's problem. Thanks for looking into this.

        • (Score: 0) by Anonymous Coward on Tuesday June 30 2020, @12:35AM

          by Anonymous Coward on Tuesday June 30 2020, @12:35AM (#1014320)

          Thank you - I jump at any excuse to play with Raku, and I was upset when I saw such terrible performance. I'm not thrilled with a 6x gap, but for most tasks that's acceptable.