develooper Front page | perl.perl5.porters | Postings from February 2013

Re: Perl 7 or Perl 2013?

Thread Previous | Thread Next
From:
Alexander Hartmaier
Date:
February 7, 2013 22:01
Subject:
Re: Perl 7 or Perl 2013?
Message ID:
CAB49QrYrp3a7QgPjiRGyw0faf6Q6WJMDkxDOqCGmbLVSorAM1g@mail.gmail.com
On Thu, Feb 7, 2013 at 6:03 PM, Joel Berger <joel.a.berger@gmail.com> wrote:

>
> From: Ricardo Signes <perl.p5p@rjbs.manxome.org>
>> To: Ovid <curtis.poe@gmail.com>
>> Cc: perl5-porters@perl.org
>> Date: Wed, 6 Feb 2013 13:45:27 -0500
>> Subject: Re: Perl 7 or Perl 2013?
>>
>>
>> This topic has come up many times in the past few years.  It is generally
>> in
>> the form "let's call the next one Perl 7" or "let's hide the 5 and call it
>> version 18" and sometimes "Perl $Year."
>>
>> These all say, "Perl is the language, and Perl 6 is something irrelevant."
>> This is specifically in contradiction to Larry, who has *specifically* and
>> *repeatedly* addressed this point in keynotes and other public
>> presentations.
>>
>> We can't call it "Perl {$x>5}" without contradicting Larry, and if some
>> folks
>> are interested in organizing a committee to badger Larry *even more*
>> about this
>> issue, the most I can really do is say that this isn't the place to do
>> organize
>> such a committee.  I'd also like to say that this has been addressed so
>> many
>> times that further pressing of the issue seems inappropriate.
>>
>> Furthermore, were Perl 7 to be released (secretly known to be Perl
>> 5.20.0),
>> what would the outcome be?  It would gain attention, and people would say,
>> "Wow, a big new release of Perl?  What's new?  Oh.  Not very much!  Ho
>> hum."
>> It gets us attention and then squanders it, because it isn't able to
>> deliver on
>> "all the amazing cool new stuff."  What's amazing and cool since 5.8?
>>  Many
>> excellent features ranging from "small but very handy" to "significant and
>> useful in some circumstances."  I am delighted to have s///r and lexical
>> subs
>> and (soon) subroutine signatures, but if the notion is that people think
>> nothing has happened in 10 years, and the answer they get is those, I
>> think we
>> will appear desperate rather than vibrant.
>>
>> --
>> rjbs
>>
>>
> Hi Ricardo,
>
> First and foremost, I want to say that, I realize that I'm new to the Perl
> community. I also hope that I even post this message correctly! I know I
> don't get much of a vote in this as such, but I want to respond to this
> comment because I feel strongly about it.
>
> I learned Perl mostly from perldoc and StackOverflow. I am very familiar
> both from when I was a noob and now as I try to help the noobs, what some
> of the sentiment is. One that I see often is "should/must I use strict and
> warnings?" (http://stackoverflow.com/search?q=%5Bperl%5D+strict+warnings)
> or else they have problems that would have been solved if they did. The
> inevitable question then is "why aren't these the defaults?" and the answer
> is always backward compatibility, and rightly so.
>
> The same thing happens (though less often) with unicode. There is of
> course the famous rant from tchrist:
> http://stackoverflow.com/q/6162484/468327 which by the way ranks as the
> all time most voted [Perl] question on SO. Perl now has great unicode
> support, but it can't be enabled by default (even those features which make
> sense to autoenable). In fact even the default encoding of the scripts and
> the handles can't be changed.
>
> There are more nits like indirect object syntax which people trip over,
> `or die $!` on opens, and other nits that mostly remain for backwards
> compatibility. Wouldn't it be great if we could enable `no indirect` or
> `use autodie` by default?
>
> I think the biggest thing a breaking release (I personally favor Perl 7)
> would bring is a chance to flip those defaults. Perl 7 could still support
> all those ancient scripts; they would just need a few lines at the top to
> re-enable those old features. Think `no strict; use indirect`. (In fact I
> would favor a special casing of (s)?print(f)? because changing all the
> `print STDERR ...` might be over-burdensome.
>
> These are things that the outside community either sees first and thinks
> "man I need too much boilerplate" or "gosh why don't they just fix these
> things" and leave or gripe, or else they don't know to think that and
> discover that Perl without a safety net is too much trouble and just leave
> and we never knew they were there.
>
> Much of what I've written here is echoed in my blog post,
> http://blogs.perl.org/users/joel_berger/2013/02/on-the-version-number-succeeding-perl-5.html .
> I hope you'll consider a Perl 7 (or whatever) as a chance not to just make
> a publicity splash with a new number, but take it as an opportunity to fix
> some things that really do hurt Perl's perception in the first few weeks of
> learning it, which is a crucial time to woo a potential future
> core-contributor.
>
> "Perl 7, the product of years of experience with Perl 5, now with the
> defaults that help you get going faster. Don't worry about your old
> scripts, they work too with just a few minor additions." Sounds nice to me.
>
> Thank you for reading and thank you for all your work making Perl X great!
>
> Joel Berger
>
I was thinking the same an hour ago while reflecting on the topic.
For me a major version number bump means that something has changed which
requires me to look into compatibility.
I've started somewhere around late Perl 5.6, early 5.8 and can't remember
that I ever had to change a single line of code when upgrading my Perl
interpreter.
If p5p decides to ditch some of the old burdens like indirect object
notation, non-strict mode by default, no warnings by default, 2-arg open
(and 1-arg open as I recently learned) I'll gladly update every of my CPAN
modules and my $work code.
My feeling is that p5p cares too much about backward compatibility! Old
code will run on old Perl versions, they won't stop doing that when a new
Perl version is released!
And if there is an easy way to have more than one Perl version on a server,
and with perlbrew that problem is solved, you shouldn't care!
Put a note about how to install the old version in parallel to the new one
in the release notes and be done!
If the p5p core devs can finally agree on making backward-compatibility
changes I'll propose to start a list of things that should be changed and
removed (and maybe even some added /me looks at method signatures).
This list should be made public so people outside our famous echo chamber
could see that we advance and to also add their feedback and feature wishes
to the list.

Lets get this rolling!
-Alex

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About