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

Re: Perl 7 or Perl 2013?

Thread Previous | Thread Next
From:
John Imrie
Date:
February 7, 2013 21:24
Subject:
Re: Perl 7 or Perl 2013?
Message ID:
51141B6E.6070301@virginmedia.com
On 07/02/2013 17:03, Joel Berger wrote:
>
>     From: Ricardo Signes <perl.p5p@rjbs.manxome.org
>     <mailto:perl.p5p@rjbs.manxome.org>>
>     To: Ovid <curtis.poe@gmail.com <mailto:curtis.poe@gmail.com>>
>     Cc: perl5-porters@perl.org <mailto: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 quite like this Idea.

It gives us a reason to bump the major number as all the defaults change.

As an addition could we come to an agreement that the Perl6 crowd can 
have the even numbers. Perl 6, Perl 8  etc. and we get the odd one's. 
Perl5, Perl7 etc.

John

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