On Perl 7 and the Perl Steering Committee

While difficult, determining which questions to ask is an excellent step forward.

I have 99.9999% no problems with this post. Thank you Ricardo for a very useful document. Just one thing...

Perl, version 7 "fork"? I believe that if there is a "fork" of Perl to be described, it's Raku. THAT was supposed to be the next Perl. And the people involved in it decided that the VERY NAME OF THE THING IT WAS SUPPOSED TO IMPROVE was a millstone around their necks and ABANDONED it. THEY FORKED. And so, ok, fine, just take 20 years of development, move on, and kick the rest of us to the curb, but let's be real here about who broke away and who stayed the course.

Ok. Now that THAT is off my chest...

For those who are complaining about Perl version 7, the proposal and/or Perl version 7, the process, let's be realistic: the Perl version 7 attempt wasn't going to happen by sitting around and platypussing it. The last time a committee got together to improve Perl it took 20 YEARS and THEY ABANDONED THE COMMUNITY they were supposed to be improving. Sometimes you need a proposal and a target to shoot at. We now have one. It is bounded and explicit:

- Version 7 is a major release. Major releases break backward compatibility. That's the way things work in Open Source and semantic versioning.
- Version 5 will be maintained until you can get to version 7. If you even want to.
- Version 7.0 will simply be changing defaults. A bit more discipline. Big. Deal. That is a characteristic that a professional language should have anyway. That's something professional programmers should do anyway.
- Versions 7.2/7.4 are planned to have real function signatures and a real OO system, order yet to be determined. Those are characteristica that a professional language should have anyway.

By bringing Perl into *really* using semantic versioning, we can grow the language with a contract. We've put up with lack of growth for 20 years. Things that don't grow
die. The discussion that ensued after the announcement looks like is has already influenced the direction: 'use v7' directive and the idea of NOT enforcing strictures for -e scripts (that's what -E is for anyway).

So, we have a reasonably scoped target that shouldn't sprawl out over 20 years, conversations that are influencing that target, and more buzz around our language than I've seen in years.

Thank you Sawyer, et. al. for jumpstarting the conversation. It is said that you can tell the true pioneers by the arrows in their backs.

And I apologize for all of the ALL CAPS. But you really have no idea how ticked off it makes me that Perl version 7 is described as a 'fork' when there's Raku.

I feel like the idea of Perl 7 has a brother spirit in the idea of Perl 6, which was also its demise (Raku is now admitted to be a whole new thing altogether, and the traction it has smaller than that of Python 3.0). It simply doesn't take into account how people actually work and use tools.

Perl 7 is Perl 5.32 with changed defaults.

Which means it effectively has zero actual advantages over Perl 5.32.

Which, given it also breaks existing modules (because they are old, unmaintained, but have no practical alternative; CPAN is aging and this is a fact, despite whatever wishful thinking may the fans apply), means the number of advantages over Perl 5.32 is negative.

This also means that people who actually write software will need to wait for 7.008 or so before it grows a compelling enough feature which will be worth it to cope with breakages (native async, or yield?). Remember, it took Python 3 at least five iterations before bigger libraries could be ported. Some argue it was 6 iterations, and some tell that the damage was irreversible anyway. I'm not with those whiners, but some of their arguments are hard to refute.

Thus it means that 7.000 is only of interest to tinkerers with Perl itself. AKA not useful to the general public.

It was not unlike with Perl 6, where there was a big debate around the spec, then a big debate around runtime, and gosh do those years fly fast.

All stick and no carrot.

When you make a breaking change in your product, at least slip in a feature which will make the breakage worthwhile. And for pete's sake, start borrowing good things from the languages that proved over the last decade to be more successful.

Compared to the rest of the perl users and programmers, I'm definitely a newbie. My first programming language is PHP back in 2001 when perl was already established in linux. I'm not well entrenched in with the perl crowd but have always have had a great amount of respect for perl and for Larry. Heck, English isn't even my first language, Traditional Chinese is. With that said, I hope my relative distance from all of the drama and state of languages can provide some perspective.

I came to programming relatively late in game probably compared to all of you guys. But what I saw back then was a community that made sense in a world (outside of computers) that was ridden with vanity and self-interest. Every computer language was a different approach to problems. ASM for direct communication with computers. C++ for highly structured and efficient coding, PHP for loose and casual web coding and Perl for resolving (human or otherwise) language-based problems. Maybe it was my naive-ness from my youth, but I didn't see a lot of hate or flaming or lane tripping from one language to the next. So I don't know why all the hate and yelling and demanding is happening in a community that, with my admittedly limited exposure, was so nice to me when I Perl. When I learned Java, all the forums were filled with phrases like "what you should be doing is..." or "why are you doing that? you need to solve it like this." Qt is filled with "Why are you asking?" or "Why don't you know already?". Perl has always been "Here's your problem, it's a misunderstanding about this. Here's about 5 ways to solve your issue and the documentation of what you misunderstood."

I bring all this up because I feel like, and maybe I'm wrong, that the people that are trying to figure out where to take Perl next is more worried about popularity than they are about logic. If we defined the language to be a tool to solve language problems, the goals of where to go from there should be clear. What changes/improvements/additions can be provide to further that initial goal? If features are added to for the sake of conformity and/or familiarity, then the entire point of the language/tool is lost. In which case, no matter how popular it is or or how much of an user base, a tool without a function is no better than a random rock picked up off the ground. Yeah, a lot of people have access to random rocks. But I'm pretty sure no one is building skyscrapers or cars with random rocks for a reason.

So, let's address the bird and snake in the room. PHP and Python. Being a long-time PHP fan, I can say that PHP's backwards compatibility breakage is almost less breakage than cleaning house. PHP's backwards compatibility breakage worked because of a few things. 1) A long period of notice of deprecation while gives people time to adapt (on a personal level) and change (code). 2) The breakage happens for a solid reason that reflects the goals of the tool. A good example are mysqli. magic string and changing the global variables. All were done for either faster speeds and/or security reasons. 3) The breakages didn't compromise the core purpose/language. I have a site that I wrote starting back in 2004. To this day (still use it for my own purposes to this day), the only thing I had to update was the mysql connector. Python, however, is a good example of what not to do. Python, from it's introduction to many, was a solution looking for a problem. It boasted regex that had to be loaded after the fact. To quote the wikipedia article:
"Rather than having all of its functionality built into its core, Python was designed to be highly extensible. This compact modularity has made it particularly popular as a means of adding programmable interfaces to existing applications. Van Rossum's vision of a small core language with a large standard library and easily extensible interpreter stemmed from his frustrations with ABC, which espoused the opposite approach.[35]"
It's trying to be all things at all times. But the truth of the matter is, matter, energy and time in the universe is finite. As such, nothing can be all things. And while Perl is often called a swiss army knife, that's not because it was all things to all people. It's because what it's built for can be applied to a lot of things. Reading all thing, one might wonder why Python is so popular while Perl is not. To that, I can say Python is popular for 3 reasons. 1) Once you learn it, it locks you in. Tuples are ordered arrays. Dictionary are hashes. The difference between the two names is, arrays are called the same thing in most languages while tuples are used in only a few. 2) It's easy and lazy. And while sometimes those can be good things, most of the time it's not. 3) It's popular because it's popular. Very rarely do I hear good things about python programmers. Those that I do hear good things from are usually Python programmers. Having a very vocal user base does help in spreading the word of it's benefits, but it does nothing to address the problems with the code itself. But, the more people talk about it, the more people listen. And those that don't know or haven't used it (or if that's all they used) will attest to how good it is because other people say so, a lot of people are using it or it's easy. Of all the different languages I've had to deal with since those early days in 2001, Python code has consistently been that fail or crash due to bugs, poor design or just passage of time.

Getting back to Perl, I feel that this article and the email in it is trying to chase Python more than steal from PHP (which, as a PHP user, by all means. PHP stole a lot from Perl in the beginning and I think PHP would be honored to give something back.) . And maybe it's because we were all nerds at some point and we want to chase after a popularity we never had in our younger days. But the truth is, popularity contests have no real validity, logistical reasoning or good outcome in the end. Anytime something or someone achieves good things, it's not because they were popular, but rather they did good things. Popularity only broadcasts said achievement. And I know that a language dies if no one uses it or very little people use it. But consider this. Perl was made from one man. And it grew because it was useful. And while it would suck for Perl to be reduced to an one man team again, that would be preferable to a tool that has a large user base but no real strengths and/or advantages. I know that I, for one, if need be will retain and use Perl until the bitter end. Even if all the user base is gone and the committee is gone. As long as it's a good tool, I will keep it, use it and sing it's praises. Besides, very rarely does chasing after something else's user base turn out well. Because, if they already like the original, why would they something that it trying to be exactly the original? Just as an analogy (since I am Taiwanese), having business dealings with China and setting up in China was popular. But in the end, when push comes to shove, it's not the big wealthy and loud country that is a dependable partner. But the one that does the right thing and let it's action speak for themselves.

Lastly, on a personal note. I know Javascript and Python are the most used languages in the industry. Heck, even my job is mostly javascript these days (yes, I did end up becoming a programmer.). But the truth is, when I'm at home or when I need to get something done quickly, it's not node or javascript or python or c# or any of the other modern popular languages I turn to. It's Perl. Case in point. 3 jobs ago, we were building an react app with a node.js backend. At some point, we were using example data for the ORM. That example data had to be updated. But since it's ORM, it wasn't a simple search and replace. The lead programmer decided we should just grit our teeth and bear it. I asked why because I could update the code in like 20 minutes. No one on my team believed me because they couldn't do it in node or javascript or python. I insisted that it's easy in Perl. They reluctantly give me time to try saying something along the lines of how ugly Perl is and no one would want to maintain the code. I did it in 40 because I wanted the code to be extendable. When it was done, they still didn't quite believe me. When I showed them, they were in awe/disbelief. They then asked me to add the lone Perl script into the repository of javascript and node.js code. Which just goes to show, what's popular, new and/or standard isn't always good. I think we, as linux users, should know that better than anyone.

I know my voice is but a small one. I do hope it provides some insight. I hope it will invoke some change for the better. Thank you for taking your time to read this.

No, "Perl 7" is a silly idea. Perl is an old and established programming language from the Unix timesharing era, so one would expect it to have been feature-complete twenty years ago. As such it's wildly inappropriate[0] to either introduce changes that break backward compatibility, or, especially, pull another fucking Osborne maneuver on it. By now Perl should be updated like C is: every 12 years, very carefully and very very little at a time.

It's even more damning when seemingly none of the available discourse covers what changes, in particular, are there in the pipeline. Rather, it all seems like a bunch of meta w-k about hypothetical revisions that exist only as a vague sense of quarantine malaise. Worse, there seems to be a desire of certain "Perl 7" people to nick off with the runtime, its developers, and a majority of "the Perl community", and have their own "Perl 6" with blackjack and hookers, like their absence was ever the problem.

That suggests that the revisionists aren't confident in the validity or desirability of their changes as they relate to Perl as it stands today, but would be if Perl were reinvented as a green-field project instead. However, today's green-field programming languages are semantically identical[1] except for their authors' personal wibble; and while some of them may survive into the early 2030s, most will go the way of Delphi, SmallTalk, and Prolog. So the changes are discussed in the abstract, pre-filtered with the necessarily starry-eyed value calls of their own authors. Since abstract things need not be pinned down, discussion can continue until the last hold-outs have been worn down. How is that not "missives from the Secret Above" in effect?

Let these fools be the ones forking Perl, and calling it something else; see if "the community" runs right after them for all the cool new stuff they don't have. They can even name it Zim, after the enchanter.

This goes for hipster control flow du jour as well: if it ain't from Algol, it's syntax sugar. Perl has that to a degree where it doesn't need a macro language or preprocessor, which is cool as hell. Rather than import dumb syntax from other languages for silly reasons like boot-camp compatibility (i.e. looking like JavaScript), They Ort Ta check every half-dozen years or so for recently-established features that survived the neverending human wave of easily-impressed newbies[2].

[0] among others, it's a massive disservice to huge existing code bases, which lose all the validation that can be had from having been in production on one of the few properly stable languages around. "oh, I upgraded perl and now half my regular programs are filling up stderr with deprecation warnings."
[1] these languages have equivalent features which rather than the authors wanting to have, were unable to avoid. For example, their for-each syntax is either limited to built-in array types, or there's an IEnumerable in the standard library -- so there must also be a form of polymorphism that's visible (and therefore tied) to the compiler.
[2] newbies, being new, will sing praises and persecute heretics in the name of (say) design-by-contract, because that's all they know. Some will always be newbies, hopping from friendly tutorial hugbox to another forevermore.