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: 0) by Anonymous Coward on Monday June 29 2020, @01:42PM (2 children)
"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: 2) by RS3 on Monday June 29 2020, @02:55PM (1 child)
IIRC, perl does pattern / string stuff better. I'm not doing enough coding to have a feel for this, but how does this factor in? https://www.infoworld.com/article/3563840/python-may-get-pattern-matching-syntax.html [infoworld.com]
(Score: 2) by The Mighty Buzzard on Monday June 29 2020, @09:05PM
If by "better" you mean "kicks the everloving shit out of the nearest competition", you would indeed be correct.
My rights don't end where your fear begins.