Re: Curious about Perl's strengths in 2018

[BrowserUk]

In the betamax vs VHS of computer languages, Perl is VHS; but it lost anyway.

Why? Is a deep, painful and complicated question, but sums up to:complacency. And the archives of this place are the evidence.

An integral part of that, is also the plague of OSS in general:cliquism. Which to lesser Eng.lit. mortals means: the propensity to subdivide rather than reach a compromise; but with a twist.

Whilst there are a billion(*) varieties of Linux, because noone group can decide what it should be; there is only one Perl, because no-one outside the ruling clique -- which includes the author, who is also on the outside looking in -- is allowed to suggest, much less make, changes. Stagnation rules.

That false god of antiquity, namely 'backward compatibility', has been deemed all-powerful and sacrosanct, by the anointed -- for the most part by virtue of being around at the time -- few, with the result that even fixes aren't allowed to break even the most broken and ill-designed of existing 'working code'. The result is inevitable: stagnation.

Circa 2005, perl's core code needed to be re-written for the modern world. I'm talking internally, not semantics. Less global state; less God objects; less magic; less 'only Perl can parse Perl; in a way, less TIMTOWTDI, but to a very small extent. Perl, circa 5.10.1 was nearly the perfect base from which to take over the world; but it was too hard. In testament to the vision and skill and genius of the original author, perl's internals proved impenetrable to refactoring at anything more than the most superficial of levels, so those in the-clique settled, for ongoing mediocrity. And here we are today.

Some will condemn me -- and this -- as the ravings of an anti-Perl outsider; nothing could be further from the truth. Having once condemned Perl to being a "read-only language", I learnt to first hate; then accept the need for; learn to work with; then admire; and finally, love Perl. And I still do.

It's only perl I am critical of. And if/when you come to understand that dichotomy, will you begin to understand the pain it causes me to write this. To write, what I consider to be, the truth about Perl.

(*)292 more or less different distributions the last time I counted.)

[dave_the_m]

Circa 2005, perl's core code needed to be re-written for the modern world

That was realised far before then. Chip's Topaz project to write a new, modern C++ perl core, kicked off in 1999, IIRC. It failed. Then there was another major attempt in 2000. That became perl6, and took 18 years. In the meantime, some of us have been keeping the existing perl5 core ticking over. We haven't been stopping anyone from forking the core and modernising it in Their Own Image - for example Kurila and cperl.

We are however regularly accused of being Evil and breaking backwards compatibility on every new release. You only need to install a Marc Lehman mode from CPAN to get a virtual earful on how capricious the Porters supposedly are.

Then we get in the neck from a second group of people on how evil we are for not rewriting perl in a shiny new modern way and be damned with old scripts still running.

I think we have attempted to steer a reasonable middle course. We don't get it right all the time of course.

Dave.

[BrowserUk]

You are the exception that proves the rule Dave. You engage. And I (amongst many others I'm sure) have learnt a raft of stuff from that.

And I know there are a bunch of others that have done, and continue to do sterling work in the background.

But there are also a bunch of high-tower sitters in the clique that sit on anything that is NIH.

And as for forking -- that way lies 200 incompatible versions each with one main contributor.

[LanX]

Dave, with all due respect.

It doesn't make Perl's management look efficient, if it takes about 20 ok lets say 15 years to implement experimental subroutine signatures, and this only including positional and no named parameters.

[dave_the_m]

It doesn't make Perl's management look efficient

It's very little to do with management (efficient or otherwise), and mainly to do with lack of manpower. Specifically there's a whole bunch of stuff I am aware of that needs pinning down and then implementing, before signatures can become non-experimental.

As one example, consider the behaviour of @_ within the body of a signatured sub. Should it still contain the full argument list (but then you incur the cost of setting up and restoring @_ for each call), or be empty (you still have a setup/restore cost), or be untouched and still have the value it had before the current function was called? Should accessing / modifying @_ trigger a warning, or even be fatal? What happens when a function is called via the argless &foo; mechanism - for each of the combinations of caller/callee being an ordinary/signatured sub? If @_ isn't populated, how can the sub tell whether a particular arg got passed a real undef value or no value? Should the behaviour of @_ be controllable? If so, should that be via a pragma or some new syntax within the signature? (Those are all rhetorical questions - I don't want to get into a debate about signature semantics here.)

Until all that has been decided and implemented, we don't know how @_ will change, so can't mark it as non-experimental.

Deciding and implementing all that is currently in my balliwick, and I only have so much time.

Dave.

[Laurent_R]

That false god of antiquity, namely 'backward compatibility', has been deemed all-powerful and sacrosanct, by the anointed -- for the most part by virtue of being around at the time -- few, with the result that even fixes aren't allowed to break even the most broken and ill-designed of existing 'working code'. The result is inevitable: stagnation.

I fully agree with this. IMHO, backward compatibility is usually a very good idea, but it becomes an obstacle to progress when it is maintained for too many years. We're speaking here about more than three decades. Nowadays, we really should no longer insist on keeping compatibility with Perl 4 programs written 25++ years ago. Strictures, warnings, lexical scope, lexical filehandles, autodie (or, at the very least least, autodie qw(open close)), and other such 'modern' features, should be the standard Perl behavior today, while keeping the no pragma_xxx possibility for programs written in the old style.

Perl 6 is a bold attempt to do that. I know that many people here tend to frown upon it because they think it is breaking too much the backward compatibility. "Gosh, it took me so long to learn the sigil change when accessing an individual item in an array or a hash;" I can readily understand this point of view; very often, when I started to use it, I asked myself: "Damned, why did they change that (specific feature)? It worked well without that change." Well, maybe Perl 6 changed too many things. Or maybe not. It is very hard to say what the optimal amount of change might have been. So, in brief, I can understand this reaction very well, but I think it is wrong: after having used Perl 6 for quite a few years by now, I know that these changes do make sense and really make the language much more consistent. And, frankly, Perl 6 is really easy to learn for an old Perl 5 user like me (who is still using Perl 5 almost everyday at work and loves to do so).

[LanX]

> because no-one outside the ruling clique ... is allowed to suggest, much less make, changes.

you might like http://perl11.org/cperl/STATUS.html

(Funny, when I read the description I can hear Reini's voice ... ;-)

[karlgoethebier]

"... Less global state; less God objects; less magic; less 'only Perl can parse Perl; in a way, less TIMTOWTD..."

He, our beloved supreme leader is an apostate?