On Mon, May 27, 2013 at 11:11:49AM +0200, Michael Panteleit
<[email protected]> wrote:
> Oh, come on, don't bash these people. They are trying to keep perl
> healthy and alive.
There is ample evidence against that with 5.18. I suspect your definition
of "healthy and alive, however, includes "breaking compatibility and
support for existing perl code in favour of experimental toys", in which
you would be right of course.
> The construct which is leading to this error now is being flagged as
> deprecated since perl 5.13.11. And now it's eventually removed.
You are singling out a single problem here, ignoring the bulk of them.
The change in hash randomisation alone broke ~100 modules for example,
and the trend didn't start with 5.18, 5.10 already started introducing
widespread XS breakage that to my knowledge has not been fixed either. As
I have a lot of modules and am writing modules for decades, I am very
sensitive to such changes, even if they are mostly invisible to you - it's
me who is doing the work.
The only difference between 5.18 and earlier is the massive amount of
incompatibilities caused by it. The accelerated release schedule also
means that a lot of very badly thought-out changes to the language have
been introduced, canged, changed again etc. (given/when being lexical
while other block constructs are dynamic, the fiasco with smart matches
and many more). It also means a lot of extra work for cpan authors who
have to work around breakage in perl every few months now, which causes a
great additional burden.
That might well be what you mean with "keeping it alive", but ignoring the
enourmous bulk of code that exists and *works*, and relies on a certain
amount of stability, is what keeps perl alive for many other people,
including me.
Changing perl into a python or other language clone doesn't seem to help
it (thats my personal opinion of course). And of course, python doesn't
introduce so widespread breakage so regularly either.
> This side effect of qw has now been abolished. It has been deprecated
> since Perl v5.13.11. It is now necessary to use real parentheses
> everywhere that the grammar calls for them.
And this section you quoted is quite telling - there is no grammar for
perl, except in the source code. The documentation only works by giving a
few examples, not a formal grammar.
There are a lot of features in perl that are not documented, but are
absolutely vital for it to function (for example ::-quoting wasn't (or
isn't) documented, or the function argument evaluation order, or a large
part of the XS interface - in the past, when I reported such bugs, they
were considered bugs. Apparently that changes now).
If perl5porters now think that perl coders have to read the perl source
code for an idea on whats legal and what not, and at the same time
think that breaking anything that isn't documented according to their
interpretation of the day, then perl isn't healthy or alive, it becomes
useless for productive work.
And yes, that is a change. When I last submitted a patch to fix unicode
bugs in perl I had to make a survey of the whole of cpan to see what
modules break. The standards have changed dramatically since then.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
