Front page | perl.perl5.porters |
Postings from August 2020
Re: Q: what the hell is going on? // A: ...
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
August 6, 2020 18:02
Subject:
Re: Q: what the hell is going on? // A: ...
Message ID:
991fb43e-bb22-60fb-549f-415cd88c44b9@gmail.com
On 8/6/20 8:15 PM, Philip R Brenan wrote:
> If there are any breaking changes that are not made optional by
> pragmata then we have two classes of Perl citizens some of whom are
> more equal than others: those who decide how and when breaking
> changes will occur and the hoi polloi who must either accept these
> changes with no say or move on to another language. I believe we
> should be faithful to our creed:
>
> https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it
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[1] 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."[2] 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.
[1] "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
"say".
Thread Previous
|
Thread Next