Front page | perl.perl5.porters |
Postings from August 2020
Re: Q: what the hell is going on? // A: ...
From: TTK Ciar
August 9, 2020 20:56
Re: Q: what the hell is going on? // A: ...
Message ID: 20200809195620.GA11832@banshee.ciar.org
Could you do me a favor, please, and reconcile assertions that Perl v5 will continue to be supported with assertions elsewhere that Perl v5 will be EOL'd when Perl v8 is released?
The Perl v7/v8 EOL'ing v5 matter is throwing a wrench in my priorities, and I'm not alone. It's got me wondering if I'd be better served migrating all of my existing projects to D and python, or something.
I expect to be programming computers for a living for at least another twenty years, and need to invest my time and energy in ways which will pay dividends in the future.
EOL'ing Perl v5 would put businesses in a difficult position where they have to keep legacy Perl running, often without enough Perl programmers on staff to port the entire mess to newer Perl, but with enough programmers to attempt porting their legacy systems to another language. That means fewer employment opportunities for professional Perl programmers.
EOL'ing Perl v5 would also jeapordize those CPAN modules which are abandoned by their authors, but still useful, which IME is most of them. CPAN's vast ocean of canned solutions remains one of Perl's greatest assets, and jeapordizing that would diminish the appeal of the language.
Users could continue to use an older release of Perl, as you have said, but as platforms evolve over time, software must eventually be updated to work on modern platforms. This effort is the minimum requirement for perpetuating Perl v5.
If someone could state for the record that as long as p5p devs are willing to continue supporting Perl v5, they will continue to have permission to make official releases, it would go a long way to allaying these fears.
The maintenance of Perl v5 can and should be a completely separate issue from releasing Perl v7, v8 or any other future version.
On Thu, Aug 6, 2020 at 18:02 Sawyer X wrote:
> At the moment, without any changes, we still have more than one "class
> of Perl citizens" in which one takes priority. The question is between
> those classes. These two are prominent: 1. The developer who sees
> whatever Perl they wrote never changing and 2. the developer who wants
> the best Perl out of the box.
> The class that prefers no code ever be change once written is currently
> the first class of citizens. Their needs take priority to anything - new
> users, new features, bug fixes, speed optimizations, everything. It's
> true we've removed things, but rarely, and they are an exception.
> Reinstating bugs to not hurt existing code that refuses to change is
> more common and a much simpler decision in Perl.
> Any company that now picks up Perl (as if many would...), all of their
> developers (existing and new ones) must learn how to bring Perl to an
> acceptable level. They will add strict and warnings. The developers are
> already accustomed to function signatures (coming from practically any
> other language around) and will want that (if they know it exists) so
> will need to turn those on. They will eventually be bitten by bareword
> filehandles, by indirect syntax, and more. They will need to learn about
> them as they get bitten and learn to avoid them, debug obscure messages,
> and perhaps add additional pragmas to disable them - see "bring Perl to
> an acceptable level."
> That company that is trying to increase the use of Perl and build new
> things, as well as all of its developers, are second class citizens. Not
> in the dystopia future people are pontificating about, but right now.
> They currently matter less to the Perl language. The first class
> citizens are first class because they get a free ride with no changes at
> the cost of these developers above. In fact, we're signaling to this
> company that picking up Perl is not in the interest of the Perl language
> developers themselves. The community, in supporting this "balance," is
> signaling that Perl is not for anything new - which strongly contradicts
> all the conferences, blog posts, and pamphlets we tried pushing forward
> over the years. (Although, there are people who wish the language stay
> put - no new releases even. I'm going to avoid them for now, since
> they're welcome to use an old version of Perl - 5.6 is still available.)
> It seems like you're assuming that these developers who request their
> code never change are not coming at any expense, but this is simply not
> true. Of course, it's a bit silly when this argument is made and the
> response is "So we break everything?" as if anyone even suggested moving
> to the other extreme. We've done this. It exists. It's called Raku and
> it's great. But it isn't Perl. (Arguably, for a reason. :))
> Our position used to be "it can be broken and it can require everyone to
> continuously work around it till infinity, but code once written is
> king." We all understand this argument. Considering this evidently
> isn't helping Perl grow (and in fact makes it all the more reason to
> just rewrite existing Perl code than continue developing it - not to
> mention picking up Perl), that position needs to be challenged. Far
> beyond "should we? Nah? Okay," but much more strongly challenged. That's
> what we did at Perl Core Summits and that's what this is about.
>  "Best" is subjective. Here I'm referring to "using the best
> practices and patterns that we teach and recommend (like strict and
> warnings) and having new capabilities we introduced." In "new
> capabilities" I'm thinking more about current_sub (__SUB__), rather than