develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About