develooper Front page | perl.perl5.porters | Postings from April 2021

Re: on changing perl's behavior

Thread Previous | Thread Next
Ovid via perl5-porters
April 9, 2021 08:07
Re: on changing perl's behavior
Message ID:
  On Friday, 9 April 2021, 04:24:34 CEST, Ricardo Signes <> wrote:  
 On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:

Outside of that, when a huge win can be demonstrated, stuff should be removed, but then i'd prefer it be done by way of deprecating that specific dialect.

Christian's #2, changing defaults when they confound users, should be weighed against users confounded.  I think we'd find that in general, new users are not reaching for formats.  If users say "I'm using formats, and this part was confusing," and we say, "okay, we have ripped out formats," I don't think anybody's going to thank us for that.

Late to the party, not a core dev, and probably shouldn't wade into the lion's den, but I'd like to offer my (obviously biased) thoughts.

I have read and written on the subject of emigration for many years and I having been thinking that those issues are relevant to Perl. Why do people leave a country? There are push factors (war, famine, lack of jobs, discrimination, etc.) and pull factors (climate, jobs, culture, etc.). When push factors are the primary motivation (think "Somalia"), refugees will flee to just about any place that will take them. When pull factors are the primary motivation, people want to go there. The US and France, for example, both have plenty of (very different) pull factors and lots of people want to move to those countries.
It's even stronger for programming languages because there's not mcuh barrier to entry to other languages.
Perl has a lot of push factors (fewer jobs, old-fashioned language, frequently cryptic syntax), but what are the pull factors? I don't mean the pull factors for us. We're not the target audience here. I mean "pull factors for new developers." It's not the CPAN. It's not unicode support. PCRE is nice by most regexes I encounter in the wild aren't much more complicated than /ab(c*)de/. It's a nice glue language, but DevOps chose Ruby instead (why? push factors).

I can name push factors for Perl all day long, but pull factors? And pull factors that overcome the push factors? And make Perl more enticing than alternative languages? I could start listing push/pull factors for Python, but I don't want to start the day silently weeping into my coffee.

So, some points that I think are important:

   - If we break back-compat silently, people won't blame the sysadmin who upgraded without checking. They'll blame Perl. That's a new push factor.   

   - I don't hear other devs saying I won't use Perl because of <insert unpopular feature here>. They say "I won't use Perl because it's Perl." We could use this bullet point to list many, many push factors.   

   - Perl will die unless we give people a reason to try it again (and I agree that new OOP isn't the solution, but I contend that it's part of it). We need lots of pull factors.   

Saying we should just keep Perl as "Perl", maybe remove some cruft is ignoring pull factors. It's saying "I want to go gentle into that good night." Perl will continue it's long slide into irrelevancy and people who enjoy Perl will have to find other ways of paying the bills. Make developers sit up and say "I want that!" When I give intro Raku talks, developers sit up and say "I want that.!" They say that about numerous features. They don't say that about Perl. (That's not saying anything about whether or not Raku will be successful)
So, given the assumption that Perl's push/pull ratio is poor, I contend that only a wholesale, radical upgrade of the language is the only way to save it.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About