|
in reply to Re^12: Curious about Perl's strengths in 2018
in thread Curious about Perl's strengths in 2018
These examples sound like XS code exploiting undocumented or internal features, without being widely used.
Manipulating the OP Tree? Does really anyone seriously use B::Generate ?
I'd be interested to see official API which would break with signatures
I can't see how 3rd party modules like Function::Parameters break XS code while implementing most of Perl6 semantics.*
It's a matter of management to introduce an experimental feature and give module maintainers exploiting undocumented stuff a time span to fix their code (or not).
The benefits of decent signatures outweighs any possible damage.
And not all modules are as important as JSON::XS and not all maintainers are reluctant to improvement like Schmorp is.
I hope you see my point.
*) and it might be worth checking if cperl's implementation of signatures broke any official XS API. |
Re^14: Curious about Perl's strengths in 2018
by dave_the_m (Monsignor) on Apr 23, 2018 at 21:55 UTC
|
These examples sound like XS code exploiting undocumented or internal features, without being widely used.
I think that this really demonstrates that you have a rather idealistic view of perl core development. In reality, lots of things we change break CPAN modules, and people shout at us. And even if the module was being naughty, we're often told in no uncertain terms that because that module is a dependency for lots of other CPAN distributions we need to fix the module or roll back the perl change.
For example, if you install Moose, you pull in the following XS dependencies, some of which quite blatantly violate the XS API, or skirt its edges:
Package::Stash::XS
Params::Util
Class::Load::XS
Sub::Identify
Sub::Name
Variable::Magic
Devel::Caller
Devel::LexAlias
PadWalker
and it might be worth checking if cperl's implementation of signatures broke any official XS API
cperl's implementation is based on perl's implementation, plus my OP_SIGNATURE optimisation work, which I felt wasn't yet in a good enough state to merge into blead, but Reini decided it was ok for cperl. Other than that, the main differences are that cperl eliminates @_, and conflates signatures and prototypes.
Did it break the XS API? That depends on your point of view. For example, It added a new op (as did the perl implementation), and part of the XS API allows you to hook into the peephole optimiser. If an XS module which does additional peephole optimisation crashes because it doesn't recognise the new OP type, is that our fault or theirs? But people don't care whose fault it is if you can no longer install Moose, say - they just want sometime to fix the problem.
Dave. | [reply]
[d/l] |
|
|
Many of these XS modules build on PadWalker or offer a pure Perl fall back or reflect inspection which should be supported by a stable API.
But I don't wanna discuss Moose, there are good reasons why I prefer Moo.
(Ironically I never published my Macro module on cpan because I couldn't get rid of PadWalker dependency)
You and Reini are obsessed of speed, that's why you try to eliminate @_.
But Ruby convinced people as a "cleaner Perl" while being half as fast.
Mind you that computers became 1000 times faster in 15 years* and try to calculate the positive effect of "slow" signatures introduced in the early 2000s.
Did anyone yell at you because the experimental signature implementation breaks anything? It's just syntactic sugar injecting pure Perl code in the body. (Well except of me? ;-) I told my clients not to use it, because if the API for named args is missing, the risk of another "smart-match" disaster is too big.
We are becoming a community of grandpa's who want no change and are driving away fresh blood which can't find confidence in a language which not only lacks signatures, but can't evolve anymore and seems to be locked in a dead end of evolution.
*) More's law
| [reply] |
|
|
Did anyone yell at you because the experimental signature implementation breaks anything?
Yes they did as a matter of fact. (Off the top of my head, lvalue subs got broken).
It's just syntactic sugar injecting pure Perl code in the body
No it isn't. Both perl (5.26.0 onwards) and cperl added specific new ops internally to support signatures.
Anyway, I'm not arguing with you any more. I've explained at great length to you various technical and logistical reasons why perl hasn't been getting lots of new features, and you just keep repeating your original complaints.
Bye!
Dave.
| [reply] |
|
|
Re^14: Curious about Perl's strengths in 2018
by chromatic (Archbishop) on Apr 24, 2018 at 16:46 UTC
|
These examples sound like XS code exploiting undocumented or internal features, without being widely used.
For a long time, there was no strong line between "documented" and "internal only features" in XS. Furthermore, there's still a persistent belief that CPAN modules should support dozens of releases of multiple stable major versions of Perl going back multiple years.
XS-as-extension language being the same as XS-as-implementation-language is a big blocker to major internal rewrites. If a solution to that had begun in 2000/2001 (instead of wasting a decade and a half producing Advanced Perl Substitute), we might be seeing the benefits of it now.
| [reply] |
|
|
| [reply] |
|
|
Given how many experienced porters P6 burned out and chased off (Dan, Simon, Chip, Nick, Artur, Hugo, a few more that don't immediately come to mind), I still suspect that things could have been different if all that energy weren't wasted going down a dead end.
| [reply] |
|
|
|
|
| |
|
Well lack of management, vision and strategy replaced with pseudo religious hubris.
Ironically does the Mythical Man Month already predict how a "second system" becomes overloaded and impossible to implement.
Well the first good argument for Perl 6 I heard was that maintenance will become much easier. It was a certain chromatic who convinced me...;)
Anyway in absence of a time machine we should concentrate on what is left and get rid of the weird 10% legacy which hinder the evolution of the remaining 90% of Perl 5.
| [reply] |
|
|
Ironically does the Mythical Man Month already predict how a "second system" becomes overloaded and impossible to implement
From the beginning, the Perl 6 folks were well aware of Brooks' famous aphorism, even using it in their slogan
(Apocalypse 12):
The official unofficial slogan of Perl 6 is "Second System Syndrome Done Right!"
From InfoWorld Larry Wall Interview (2015):
So early on, our slogan, or at least one of them, was "Second System Syndrome Done Right."
And how do you do that? Well, you just have to take long enough.
Companies can't do that because they have a bottom line and a burn rate.
But we're an open source community, not needing to make a profit, only to do good in the world.
So you know the saying, "Good, fast, cheap: pick two."
Well, by definition our community has to do it cheap, so the saying reduces to "Good, Fast: pick one."
And we quite intentionally picked good rather than fast.
See also: Three Tales of Second System Syndrome (Perl 6, Python 3, PHP 6 circa 2015)
| [reply] |
|
|
|
|
