Re^2: Curious about Perl's strengths in 2018

[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.

[LanX]

I agree it's complicated and respect your wish to not discuss semantics here.

But that's not what I meant with management.

Function signature would have a bigger positiv impact on beginners than our declarations or defined-or // operators (to name some very popular added features not talking about smart match ~~ )

It doesn't seem like P5P (or whoever else has the final word) does strategical planning.

I'm not attacking you or asking you to invest more.

I'm just stating a lack of market thinking.