FAQ

On Sun, Jun 01, 2014 at 01:10:36AM -0500, Brad Gilbert wrote:
First off having variables with a non-printable character in its name
should have
never been added to the language. Or at the very least been deprecated
immediately in Perl 5.0.0.
Well, you are invited to play with the python/... folks if it bothers you.
This is Perl, and control-character variables are in very active use for
decades, so any lament in this area is pointless.
This feature only makes sense as a shell script replacement, which is
I am not aware of shells having such a feature - can you elaborate which
shells use control characters as variable names, and even allow them to be
used literally? The bourne shell and variants do not, for example.
It especially doesn't make any sense to use it on any package on CPAN
as not all editors will cope with it correctly. Which goes against a core
principle of Open Source software, the ability to change it.
Well, not everybody subscribes to open source movement, some people just
want to create free software (that includes me).

Also, do you have a reference that supporting every single editor is a
core principle of open source? I ask because I don't think it is, and I
think you just made this up on the spot to sound cool.
The main reason it wasn't deprecated earlier was that nobody thought
about it.
If that is true, that just reinforces the problem I point out: just thinking
of a feature doesn't allow you to deprecate it. Just because you dislike a
feature doesn't allow you to break other people's code.

It just means perlpolicy doesn't mean a thing.
As to backward compatibility, it is quite likely impossible to change the
internals without breaking at least some code.
It's actually very easy to change internals without breaking any code. It's
done many many times before every perl release. By far the vast majority of
changes do not break code.

However, you are not even talking about the issue at hand, which is
changing "externals" rather than internals. And the porblem isn't that
something was changed, the problem is that somethign was deliberately
changed to make it incompatible with earlier perl versions, with the
intent of braking more in the future, without giving a thought about
backwards compatibility.
Most of the time it is only XS code which breaks. ( We need a better API )
Well, given that you are wrong (and it's reasonably easy to check, just
count the number of check-ins between perl releases that change code and
compare that to the actual breakage resulting from it), your conclusions
are not valid.
Sometimes the code that gets broken was actually already subtly broken.
( As happened with the hash key randomization in 5.18 )
Again, a documented feature that was broken for no reason: the change
broke 100+ modules on CPAN, without actually fixing the security issue (it
wasn't necessary to break the guarantees at all/has too low entropy/is
predictable).

At least, in this case, there was a semblance of actual reason: "oh my
god, panic, somebody says there is a security bug in perl, we need to do
somethign that looks as if it's fixign something".
So we are **NOT** going for 100% compatibility for 100% of the code in the wild.
I fully agree. perlpolicy doesn't claim so. incidentally, have you
actually read it?
We are really going for more like 98%+ compatibility ( which is likely better
than other languages in our same niche ).
perlpolicy doesn't give actual percentages, but it's hard to imagine that 2%
of the language is causing signifcant harm to the rest, or that 2% of the
features need to be changed incompatibly in every release. If the
compatibility would only be 98%+ then up to 600 CPAN modules would be broken
on every release. Oh my god, it's fortunately not _that_ bad, at all.

If every perl release broke 600 CPAN modules, perl would die.

I think you just made up some numbers to look cool again.
(If you use any of the hairier areas of the language you increase the
chances that you are in the ~2% that gets broken.)
Again, this is exactly opposite of what the documented policy
guarantees. If it were true, that would mske the policy a rather big lie.
That being said, we do try very hard to not break any code
without a good reason.
Keep in mind that "we" includes me (as one of the perl AUTHORS), and you are
certainly not speaking for me.

I think you just replaced the "I" by "we" to sound more cool. Do you
have evidence that the perl authors all agree to breaking up to 600 perl
modules just because they dislike a language feature? Seriously?
( I only see one person disagreeing with the "official" reason. )
I am asking and asking, but nobody provides me with the "official" reason for
this deprecating that would hold up against perl policy. Or an actual reason
at all that isn't "I belief/wish/want it so", which isn't a reason.

I suspect really there isn't any reason, which kind of makes it hard to
disagree with it.
I believe I have said my piece, and will likely not respond further.
That's good, the amount of made-up "facts" that you added to this thread
in just one mail is staggering.

--
                 The choice of a Deliantra, the free code+content MORPG
       -----==- _GNU_ http://www.deliantra.net
       ----==-- _ generation
       ---==---(_)__ __ ____ __ Marc Lehmann
       --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
       -=====/_/_//_/\_,_/ /_/\_\

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase