Perl 7 or Perl 2013?

[Ovid]

Hi all,

No worries: I have my asbestos undies on for responses to this post: http://blogs.perl.org/users/ovid/2013/02/perl-7.html

In that I asked about the pros and cons of renaming Perl 5 to Perl 7. Toby Inkster suggested Perl 2013 (and so on).

The rationale, as cut-n-drooled from a comment I made there:

I just got back from FOSDEM and heard, again, for the umpteenth time, that since Perl had 4 "major" releases (1,2,3,4) in its first few years and hasn't had a major release since Perl 5 about 20 years ago, it's clearly "dead". I hear this every time I go to a conference that's not dedicated to Perl.

Now many of you see the glaring flaw in the above: version numbers mean nothing. Perl went from version 3 to version 4 mostly to help out a book and the Linux kernel went from 2.6 to 3.0 to celebrate an anniversary. So while version numbers may not have an intrinsic meaning, they have a huge impact on perception. With so many other languages have major version upgrades and Perl "languishing" at Perl 5 for two decades, the perception is that it's stagnant. And remember, the Perl 6 project was conceived when Perl 5 was only 7 years old. (Even Python has gone from 2 to 3 and with Django getting Python 3 support, that split is going to heal).

Meanwhile, in the minds of, oh, virtually every developer on the planet who's not in our echo chamber, Perl 6 is, logically, the successor to Perl 5. Since even Duke Nukem Forever managed to get released prior to Perl 6, Perl 6 just isn't being taken too seriously by many devs. In other words, they think Perl 5 is dying and its successor is DOA. Thus, there is no future for Perl, QED.

Since Perl 6 appears to be staying named Perl 6, why not skip the entire debate and rename Perl 5 to Perl 7? Perl 6 will likely get renamed PDQ, there will be huge amounts of press over this (much of it pretty ugly) and we can finally put to rest the silly "no major release" argument.

Perception matters and this could be (to the outside world) the single biggest shakeup to Perl in years.

Cheers,

Ovid

[Peter Rabbitson]

On Wed, Feb 06, 2013 at 04:22:17PM +0100, Ovid wrote:
> Hi all,
>
> No worries: I have my asbestos undies on for responses to this post:
> http://blogs.perl.org/users/ovid/2013/02/perl-7.html
>
> In that I asked about the pros and cons of renaming Perl 5 to Perl 7. Toby
> Inkster suggested Perl 2013 (and so on).

The 20xx sounds too much like a bad 80's movie to me :) Let's stick with
P5 v20.0

>
> The rationale, as cut-n-drooled from a comment I made there:
>
> I just got back from FOSDEM and heard, again, for the umpteenth time, that
> since Perl had 4 "major" releases (1,2,3,4) in its first few years and
> hasn't had a major release since Perl 5 about 20 years ago, it's clearly
> "dead". I hear this every time I go to a conference that's not dedicated to
> Perl.
>
> Now many of you see the glaring flaw in the above: version numbers mean
> nothing. Perl went from version 3 to version 4 mostly to help out a book
> and the Linux kernel went from 2.6 to 3.0 to celebrate an anniversary. So
> while version numbers may not have an intrinsic meaning, they have a huge
> impact on perception. With so many other languages have major version
> upgrades and Perl "languishing" at Perl 5 for two decades, the perception
> is that it's stagnant. And remember, the Perl 6 project was conceived when
> Perl 5 was only 7 years old. (Even Python has gone from 2 to 3 and with
> Django getting Python 3 support, that split is going to heal).
>
> Meanwhile, in the minds of, oh, virtually every developer on the planet
> who's not in our echo chamber, Perl 6 is, logically, the successor to Perl
> 5. Since even Duke Nukem Forever managed to get released prior to Perl 6,
> Perl 6 just isn't being taken too seriously by many devs. In other words,
> they think Perl 5 is dying and its successor is DOA. Thus, there is no
> future for Perl, QED.

From personal experience I can confirm that this is true (regardless of
whether it is rational or not)

> Since Perl 6 appears to be staying named Perl 6, why not skip the entire
> debate and rename Perl 5 to Perl 7? Perl 6 will likely get renamed PDQ,
> there will be huge amounts of press over this (much of it pretty ugly) and
> we can finally put to rest the silly "no major release" argument.

Perl 7 implies "fuck you perl6, we can do better". Or at least this is
*exactly* what it will imply to the very same irrational inividuals from
the previous paragraphs. You do not want to go down this road, unless yu
are comfortable by strangling perl6 at birth, in the eye of the wider
developer community.

Doing the linux "3 versions -> 2 versions" move is the best road we
could take (and the sooner the better)

> Perception matters and this could be (to the outside world) the single
> biggest shakeup to Perl in years.

What's more important it won't affect the community internally in *any*
way. Everyone in our echo chamber will still be aware of the awesome
work Patrick and Jonathan and Carl and Larry and countless others are
doing. Folks who are excited by the prospect of an auto-threading
language will not be any less excited, and so on. And on the other side -
folks who are utterly disapointed by perl6 will not get any more
disappointed. In other words such a move has only benefits with no
downsides. What not to like?

[Nicholas Clark]

On Wed, Feb 06, 2013 at 04:22:17PM +0100, Ovid wrote:

> Perception matters and this could be (to the outside world) the single
> biggest shakeup to Perl in years.

If nothing changes but the version number, then how does one avoid this
story being reported as "putting lipstick on a pig"?

In that, it doesn't solve the underlying flaws of Perl 5:

* the language doesn't have features that people desire (or say that they
desire)
* the internals are too complex and inflexible to permit those features to
be added

We don't actually have anything new to offer.
And that's going to be exposed very quickly.

Nicholas Clark

[Peter Rabbitson]

The problem (as I see it) is that while *we as an echo chamber* don't
have anything new to offer compared to 5.10 (roughly speaking), the
wider world never looked past 5.6. This is an effort to fix that (and
only that). Did linux 3.0 have anything new to offer? We can even "blame
Linus" for the reasoning behind such a jump.

[Alberto Simões]

On 06/02/13 15:40, Peter Rabbitson wrote:
> On Wed, Feb 06, 2013 at 04:22:17PM +0100, Ovid wrote:
>> Hi all,
>>
>> No worries: I have my asbestos undies on for responses to this post:
>> http://blogs.perl.org/users/ovid/2013/02/perl-7.html
>>
>> In that I asked about the pros and cons of renaming Perl 5 to Perl 7. Toby
>> Inkster suggested Perl 2013 (and so on).
>
> The 20xx sounds too much like a bad 80's movie to me :) Let's stick with
> P5 v20.0

+1
ambs

[demerphq]

On 6 February 2013 16:40, Peter Rabbitson <rabbi...@rabbit.us> wrote:
> On Wed, Feb 06, 2013 at 04:22:17PM +0100, Ovid wrote:
>> Hi all,
>>
>> No worries: I have my asbestos undies on for responses to this post:
>> http://blogs.perl.org/users/ovid/2013/02/perl-7.html
>>
>> In that I asked about the pros and cons of renaming Perl 5 to Perl 7. Toby
>> Inkster suggested Perl 2013 (and so on).
>
> The 20xx sounds too much like a bad 80's movie to me :) Let's stick with
> P5 v20.0

I think this is a sane solution. Make it clear that Perl 5.14.2 is
actually Perl5 v14.2, which for all intents and purposes is the case.

cheers
Yves



--
perl -Mre=debug -e "/just|another|perl|hacker/"

[Peter Martini]

+1

[Ovid]

On Wed, Feb 6, 2013 at 5:07 PM, demerphq <deme...@gmail.com> wrote:

I think this is a sane solution. Make it clear that Perl 5.14.2 is
actually Perl5 v14.2, which for all intents and purposes is the case.

cheers
Yves

I've been responding privately to a couple of folks to avoid making too many waves, but since this proposal is coming up a few times: I think we need to get rid of "5". That's the conceptual issue that people have and that they've hammered me with at FOSDEM, Linux Conf, OSCON and elsewhere. While I agree that "Perl5 v14.2" is better than what we currently have, I would love to see us bold enough to ditch the "5" altogether. Plenty of confusion would go away.

We don't need to step on Perl 6 to do this, but why should we forever have the scarlet number 5 hanging around our neck?

Cheers,

Ovid

[Peter Rabbitson]

Furthermore perl itself says so if you squint:

rabbit@Ahasver:~$ perl -v

This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi-ld

...

[Karl Williamson]

How about Perl NT ?
or "Perl, now with enzymes" ?

[Peter Rabbitson]

Because for one "Perl5" is the specification of this "Perl with OO"
thingy. Additionally by keeping *some* reference to 5, you appease
backwards compatibility fascist like me ;)

But I guess before jumping up in arms about this - can you outline your
*entire* proposal for "getting rid of 5" ? Maybe if it goes out to a
wider audience, something workable may indeed emerge.

[Ovid]

On Wed, Feb 6, 2013 at 5:18 PM, Peter Rabbitson <rabbi...@rabbit.us> wrote:

 

Because for one "Perl5" is the specification of this "Perl with OO"
thingy. Additionally by keeping *some* reference to 5, you appease
backwards compatibility fascist like me ;)

But I guess before jumping up in arms about this - can you outline your
*entire* proposal for "getting rid of 5" ? Maybe if it goes out to a
wider audience, something workable may indeed emerge.

Peter, I can't outline an entire proposal primarily because I'm just trying to get this discussion started and even I'm not sold on my own suggestion, though I lean that way :)

Much of the problem is that damned "5" which has been hanging out there for years, along with the "6" which is coming after. There's simply no way to cleanly separate those in the minds of most people (even Perl devs).

If we change the versioning to "Perl5 v$version", that's sidestepping the perception issue and I suspect it will leave people with same impression of "Perl5" as they currently have of "Perl 5".

Cheers,

Ovid

[David Golden]

On Wed, Feb 6, 2013 at 11:15 AM, Peter Rabbitson <rabbi...@rabbit.us> wrote:
> Furthermore perl itself says so if you squint:
>
> rabbit@Ahasver:~$ perl -v
>
> This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi-ld

That would be commit ded326e4 for that very rationale.

David

--
David Golden <x...@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

[Konovalov, Vadim (Vadim)** CTR **]

> From: Ovid

> On Wed, Feb 6, 2013 at 5:07 PM, demerphq wrote:
>
> > I think this is a sane solution. Make it clear that Perl 5.14.2 is
> > actually Perl5 v14.2, which for all intents and purposes is the case.

p3rl.org name was invented for a reason,
maybe Perl5 <-> PerlS ?
PerlS v16.2
"S" looks like 5 - its like de-hackerization of Perl5, although l33t h4x0r
translator thinks 'S' is more like 2, not 5 :(

(I do not really like this idea though, so nevermind :) )

> I've been responding privately to a couple of folks to avoid
> making too many waves, but since this proposal is coming up a
> few times: I think we need to get rid of "5". That's the
> conceptual issue that people have and that they've hammered
> me with at FOSDEM, Linux Conf, OSCON and elsewhere. While I
> agree that "Perl5 v14.2" is better than what we currently
> have, I would love to see us bold enough to ditch the "5"
> altogether. Plenty of confusion would go away.

++
vouz avez reason.

BR,
Vadim.

[Green, Paul]

I’ve been lurking on this list a long time and I sympathize with issue of perception. I don’t believe that the perception of “no change” is the worst of perl’s problems with adoption, but I do think it may be the easiest issue to fix.

 

There is industry precedent for dropping the leading digit; Sun Microsystems went down this path with Java. IIRC, instead of Java 1.6, they called it Java 6. I believe that internally, it is still called 1.6. Firefox is burning up their version numbers rather rapidly. That seems to be the current paradigm.

 

So I side with the folks that suggested that Perl 5.N simply be called Perl N. But I would not apply this change retroactively. I’d pick a future release, and start there. I’d also leave the internal version numbering system alone, due to all of the interactions that depend upon it.

 

So yes, this change amounts to better marketing. That’s worthwhile, in my view.

 

PG

 

 

 

 

 

[Carl Friedberg]

From: Green, Paul [mailto:Paul....@stratus.com]
Sent: Wednesday, February 06, 2013 1:04 PM
To: Ovid
Cc: perl5-...@perl.org
Subject: RE: Perl 7 or Perl 2013?

...

So yes, this change amounts to better marketing. That’s worthwhile, in my view.

 

PG

 

[>] +1 from another lurker

 

 

 

[Ed Avis]

I strongly suggest not messing with the version number unless you want to
change 'use 5.14;' to 'use 14;'. Similarly, don't change the name from Perl
to Perl5 unless you also change shebang lines to '#!/usr/bin/perl5', manual
pages to 'perl5func', and so on.

--
Ed Avis <e...@waniasset.com>

[Jesse Luehrs]

On Wed, Feb 06, 2013 at 01:45:27PM -0500, Ricardo Signes wrote:
>
> 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.

+1.

-doy

[Peter Rabbitson]

On Wed, Feb 06, 2013 at 06:48:51PM +0000, Ed Avis wrote:
> to Perl5 unless you also change shebang lines to '#!/usr/bin/perl5', manual
> pages to 'perl5func', and so on.

These last bits - we *will* have to do this regardless won't we? I don't
see a future in which perl6 ships and `perldoc perlfunc` will return the
"right" thing. Do you?

[Eric Brine]

On Wed, Feb 6, 2013 at 11:07 AM, demerphq <deme...@gmail.com> wrote:

It's not even a change since 14 is called the version internally. So if anyone asks, we can just say "We didn't change anything; the formatting of the version numbers was simply confusing people."

So is it C<<use 18;>> or  C<<use 5.018;>> (or both)?

[Alexander Hartmaier]

As Perl 6 still hasn't been released as a stable version it would be easier to rename it, better later then never, to free version numbers for Perl 5 to advance. Even if it's only on paper but some people/managers only react to such things.

[Alberto Simões]

I think this is the only sane option: rename Perl 6 to Camelia, or so.
Unfortunately I do not think that option is on the table.

Cheers
ambs

[Reini Urban]

p5p perl should be called perl5 until the end, or p5p finally extends
the language to
the point which was envisioned.

Better perls can change the naming, like perl6, perl11, moe, p2, p5p6,
gperl or other
projects which are currently going on, since p5p is in continuous
stagnation and denial,
and is not able to improve the vm.

ruby, qore, perl6 or kurila also started this way, but then changed
their syntax too much.
p5, the language, is still flexible enough to be extended. p5p not.

Renaming to perl7 is ridiculous without any notable progress.
--
Reini

[Peter Rabbitson]

On Wed, Feb 06, 2013 at 01:45:27PM -0500, Ricardo Signes wrote:
>
> 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.

But this sidesteps a *very* thorny but nevertheless real problem - Larry
has no interest in Perl5. He is interested in the evolution of Perl.
Currently this is the soon to be ready (for real, no christmas puns)
Perl6. But I am pretty sure he has no plans whatsoever for future
maintenance releases of Perl5 or anything like that. Does this mean that
this list will automatically disappear once Perl6 ships? Or will it
disappear 2-3 years after that after the bugs get finally ironed out of
Perl6? I don't think so.

This list is where most of the Perl5 stakeholders hold conversations
about Perl5. Not Perl6, not Moe. If this list isn't the appropriate one -
which is?

>
> 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.

This is a valid point from a technical perspective. But perception wise
it seems to be false. I can not explain it. I myself am disgusted by the
notion of Firefox 231.11. Yet it seems to work for them. *Really* well
at that. So maybe the folks who do man our stands on non-perl events
know a thing or two about things we don't know about...?

[Nicholas Clark]

On Thu, Feb 07, 2013 at 06:34:27AM +1100, Peter Rabbitson wrote:

> This is a valid point from a technical perspective. But perception wise
> it seems to be false. I can not explain it. I myself am disgusted by the
> notion of Firefox 231.11. Yet it seems to work for them. *Really* well
> at that. So maybe the folks who do man our stands on non-perl events
> know a thing or two about things we don't know about...?

Does it? In that I thought that they started it at least partly to keep up
with Chrome, which was the first one doing version number hyperinflation.

Secondly, I read* a specific complaint from someone that Firefox version
number bumping killed their ability to migrate work webapps from IE to
Firefox. Just as they were getting close to sign off that it worked on
Firefox 4 (I think), the whole rapid numbering started. And the transition
project was doomed, because there was no way they could re-validate every
3 months for a new "major" version number.

Of course, it's completely beside the point whether there *were* enough
changes in the next major Firefox version to break anything. But the
management perception was that there *were*.

So, if one goes to a new major version frequently, is that going to make
it even harder to get end users to upgrade? And hence lead to even more
Balkanisation of versions than we already have?

Right now, it's hard enough to get firms to consider moving from 5.8.8
(or whatever their prehistoric version of Redhat shipped)

Perl 42 (it's actually compatible with Perl 5, and all the code on CPAN)
kind of takes the shine off it. But without that, what's the perception
going to be?

Nicholas Clark

* I read it on the Internet (so it must be true) and I can't find the
reference, but it certainly seemed truthful

[Jan Dubois]

On Wed, Feb 6, 2013 at 11:49 AM, Nicholas Clark <ni...@ccl4.org> wrote:
> Secondly, I read* a specific complaint from someone that Firefox version
> number bumping killed their ability to migrate work webapps from IE to
> Firefox. Just as they were getting close to sign off that it worked on
> Firefox 4 (I think), the whole rapid numbering started. And the transition
> project was doomed, because there was no way they could re-validate every
> 3 months for a new "major" version number.

[...]

> * I read it on the Internet (so it must be true) and I can't find the
> reference, but it certainly seemed truthful

I think you were looking for this:

http://mike.kaply.com/2011/06/21/firefox-rapid-release-process/#comment-10455

Note that Mozilla *has* reacted to this issue by making "Extended
Support Releases":

https://www.mozilla.org/en-US/firefox/organizations/faq/

Cheers,
-Jan

[Nicholas Clark]

On Wed, Feb 06, 2013 at 12:10:39PM -0800, Jan Dubois wrote:
> On Wed, Feb 6, 2013 at 11:49 AM, Nicholas Clark <ni...@ccl4.org> wrote:
> > Secondly, I read* a specific complaint from someone that Firefox version
> > number bumping killed their ability to migrate work webapps from IE to
> > Firefox. Just as they were getting close to sign off that it worked on
> > Firefox 4 (I think), the whole rapid numbering started. And the transition
> > project was doomed, because there was no way they could re-validate every
> > 3 months for a new "major" version number.
> [...]
> > * I read it on the Internet (so it must be true) and I can't find the
> > reference, but it certainly seemed truthful
>
> I think you were looking for this:
>
> http://mike.kaply.com/2011/06/21/firefox-rapid-release-process/#comment-10455

It was exactly that one. Thanks

> Note that Mozilla *has* reacted to this issue by making "Extended
> Support Releases":
>
> https://www.mozilla.org/en-US/firefox/organizations/faq/

Where "Extended Support" seems to last for about 12 or 13 *months*.

That's better than nothing, but revalidation every year is still going to be
a pain. However, you get what you pay for.

Nicholas Clark

[Dave Rolsky]

On Wed, 6 Feb 2013, Ricardo Signes wrote:

> 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,

I think the bigger problem is that by not allowing a Perl 7 (or 2013 or
42), there's no way to offer a new Perl that's an evolution of Perl 5.
It's Perl 5 the backwards compatible forever language or Perl 6 the
revolution (which is coming soon?). So if someone had a serious proposal
for a non backwards-compatible evolution of Perl 5 (like, say, Moe)
they're completely shut out of the Perl name.

Maybe the name just doesn't matter that much. If something like Moe is
good enough, we'll all move to the moe-porters list and be done with it.

But still, it's hard not to be frustrated when it feels like people with a
significant interest in the future of Perl 5-like languages are told that
all future version numbers belong to a project that has significantly
fewer users, developers, and mindshare than the existing Perl 5 language
(and community).

I'm 100% okay with how long Perl 6 has taken, and this shouldn't be taken
as a criticism of that project. I think it's an interesting project, and
it's spurred a lot of good Perl 5 development. Maybe ten years from now
I'll be programming in Perl 6 on a day to day basis. But Larry's
insistence on squatting the Perl 5+X (for X >= 1) names is more and more
starting to seem like a rejection of reality, and is less justified the
longer Perl 6 takes, and the less involved he is with Perl 5.


-dave

/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/

[Peter Rabbitson]

On Wed, Feb 06, 2013 at 02:44:52PM -0600, Dave Rolsky wrote:
> On Wed, 6 Feb 2013, Ricardo Signes wrote:
>
> >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,
>
> I think the bigger problem is that by not allowing a Perl 7 (or 2013
> or 42), there's no way to offer a new Perl that's an evolution of
> Perl 5. It's Perl 5 the backwards compatible forever language or
> Perl 6 the revolution (which is coming soon?). So if someone had a
> serious proposal for a non backwards-compatible evolution of Perl 5
> (like, say, Moe) they're completely shut out of the Perl name.

Why is something that is almost Perl5 but not quite entitled to the
"Perl" name? What is wrong with say "Moe"? I for one would be one of the
first to retrofit all of my CPAN offerings to run on Moe *in addition*
to the backwards compatible to boot language these offerings were
designed for in the first place.

> Maybe the name just doesn't matter that much. If something like Moe
> is good enough, we'll all move to the moe-porters list and be done
> with it.

Not all, just those that deem it appropriate (and nothing wrong with that).

[Ævar Arnfjörð Bjarmason]

On Wed, Feb 6, 2013 at 7:45 PM, Ricardo Signes
<perl...@rjbs.manxome.org> wrote:
> We can't call it "Perl {$x>5}" without contradicting Larry.

How about "perl 2013.1, the latest implementation of Perl 5 the
language".

[bulk88]

Camelia++

[bulk88]

Note, I've grouped all my responses into 1 post for thread organization.

Peter Rabbitson wrote:
> On Wed, Feb 06, 2013 at 01:45:27PM -0500, Ricardo Signes wrote:
>> 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.

The internet drama from contradicting Larry will be free advertising for
Perl 5. It is better than typical perl articles
http://developers.slashdot.org/story/13/01/29/0235220/perls-glory-days-are-behind-it-but-it-isnt-going-anywhere

>
> But this sidesteps a *very* thorny but nevertheless real problem - Larry
> has no interest in Perl5. He is interested in the evolution of Perl.
> Currently this is the soon to be ready (for real, no christmas puns)
> Perl6. But I am pretty sure he has no plans whatsoever for future
> maintenance releases of Perl5 or anything like that. Does this mean that
> this list will automatically disappear once Perl6 ships? Or will it
> disappear 2-3 years after that after the bugs get finally ironed out of
> Perl6? I don't think so.

What stopping anyone from just upload Perl 6.2 (ex 5.18) to CPAN and be
done with it? A trademark lawsuit? Perl 6 the specification doesn't have
floating point version numbers AFAIK, and there will never be "the Perl
6 engine" by definition.

> This is a valid point from a technical perspective. But perception wise
> it seems to be false. I can not explain it. I myself am disgusted by the
> notion of Firefox 231.11. Yet it seems to work for them. *Really* well
> at that. So maybe the folks who do man our stands on non-perl events
> know a thing or two about things we don't know about...?

Let us have Perl 5's version number be the relevant the perforce
changelist number. How does Perl v150000.0 sound? It will leave FF and
Chrome in the dust. jkjk

More seriously (but I dont have an opinion on this idea), why not drop
Perl version numbers and use code names for the releases? The internal
version number becomes a integer that is ++ed sequentially (start at
5017010 and then 5017040 and then 5017200 and then 5017200). Car and
mobile phone industries both dropped unfriendly model numbers for
marketing friendly names years ago.

Ricardo Signes wrote:
> 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?

Valid point. 5.8 introduced unicode, perlio, ithreads, a very different
pack syntax, etc. Its practically a new language. Since 5.8, nothing
radical internally except for MRO IMO, (feel to to add your feature
lists). Is Perl 5 feature complete? I don't think so. But the idea of
"Perl 5 exists only for backwards compatibility with legacy code because
Perl 6 is the future so all radical people have to goto Perl 6"
mentality needs to stop. Seeing Perl 5.8 support questions online in
2012 and 2013 says something is wrong. You don't see Windows 98/NT 4
support questions in 2013 (I searched a forum I visit for anecdotal
evidence, last NT 4 question 2006 (active directory), last win98
question 2008 (driver request)). Why are there still 5.8 questions?

Peter Rabbitson wrote:
> On Wed, Feb 06, 2013 at 02:44:52PM -0600, Dave Rolsky wrote:
>> On Wed, 6 Feb 2013, Ricardo Signes wrote:
>>

>>> 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,

>> I think the bigger problem is that by not allowing a Perl 7 (or 2013
>> or 42), there's no way to offer a new Perl that's an evolution of
>> Perl 5. It's Perl 5 the backwards compatible forever language or
>> Perl 6 the revolution (which is coming soon?). So if someone had a
>> serious proposal for a non backwards-compatible evolution of Perl 5
>> (like, say, Moe) they're completely shut out of the Perl name.
>
> Why is something that is almost Perl5 but not quite entitled to the
> "Perl" name? What is wrong with say "Moe"? I for one would be one of the
> first to retrofit all of my CPAN offerings to run on Moe *in addition*
> to the backwards compatible to boot language these offerings were
> designed for in the first place.

Why not rename Perl 5 if Perl 6 is taken? Someone mentioned Camelia as a
name, why not rename Perl 5 to that?

Dave Rolsky wrote:
> I'm 100% okay with how long Perl 6 has taken, and this shouldn't be
> taken as a criticism of that project. I think it's an interesting
> project, and it's spurred a lot of good Perl 5 development. Maybe ten
> years from now I'll be programming in Perl 6 on a day to day basis. But
> Larry's insistence on squatting the Perl 5+X (for X >= 1) names is more
> and more starting to seem like a rejection of reality, and is less
> justified the longer Perl 6 takes, and the less involved he is with
Perl 5.
>
>
> -dave

Agree. IMO Perl 6 is an research project, to create things to be
incorporated into production quality things. It only ends when its PI
looses funding, or is bussed. It can't be completed by definition.

Overall, something should be done. If you want nostalgia, hang a Pink
Camel ( http://www.programmingperl.org/images/20_years_of_book.jpg ) on
the wall. Put it next to the Mac Classic, and the IBM XT, a Burroughs
terminal, and PDP 11 assembly books in your house.

[Peter Rabbitson]

On Wed, Feb 06, 2013 at 07:58:18PM -0500, bulk88 wrote:
> What stopping anyone from just upload Perl 6.2 (ex 5.18) to CPAN and
> be done with it?

The PAUSE permission system (phew ;)

[demerphq]

I agree. There is an entire ecosystem involved here, peoples
livelihoods, etc, which is at risk due to this.

From what little I know of Larry his decision on this one seems pretty
out of character and I can only conclude he doesn't understand the
potential and actual harm involved.

cheers,
Yves




--
perl -Mre=debug -e "/just|another|perl|hacker/"

[Johan Vromans]

Nicholas Clark <ni...@ccl4.org> writes:

> We don't actually have anything new to offer.
> And that's going to be exposed very quickly.

We *DO* have something important to offer: Perl development is alive and
kicking. As long as people are staring blindly at Perl 6 to be the next
version, all work spent on Perl 5 is considered to be uninteresting
(just bug fixes, yeah).

-- Johan

[Brad Gilbert]

On Wed, Feb 6, 2013 at 12:45 PM, Ricardo Signes
<perl...@rjbs.manxome.org> wrote:
>
> 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.

Everybody is wrong.

It's real name is:

Perl, language number 5, version 16, revision 2

The reason we don't increment the 5 is because it is really the same language;
just with some minor, and not so minor improvements.

As far as I know the only time the language number changed without an actual
change of languages is when Perl 4 came out.

Although I suppose that means that Perl 5 is actually the 4th language named
Perl. ... Wait wasn't there a version 0?

[Nicholas Clark]

On Wed, Feb 06, 2013 at 07:58:18PM -0500, bulk88 wrote:

> Note, I've grouped all my responses into 1 post for thread organization.

That's certainly something I find makes life easier. Thanks for doing this.

> mentality needs to stop. Seeing Perl 5.8 support questions online in
> 2012 and 2013 says something is wrong. You don't see Windows 98/NT 4
> support questions in 2013 (I searched a forum I visit for anecdotal
> evidence, last NT 4 question 2006 (active directory), last win98
> question 2008 (driver request)). Why are there still 5.8 questions?

Because it's the version shipped by various Linux vendors, on releases that
they still support commercially, and still have firms using them.
And rather a lot of firms, for whatever reason, feel a lot more comfortable
using the perl binary that (they think that) their vendor supports, than
building a current version from source, even though that current version
is more capable (and almost certainly faster*)

The lag isn't going to get any *better*, as (at least) Red Hat and Canonical
have announced that their commercial support window is at least a decade.

It's not just Perl that has this. A recent rather poorly researched article
blamed us for the fact that current Red Hat is shipping a version 5.10.
That same current Red Hat version is shipping Python 2.6.6
That's *not* even the current security release version 2.6.8.
And certainly not the version that Guido would like you to be running.
(That's 3.3. Obviously. Despite the fact that no release of Django supports
it yet. Nor does Twisted. Major Python frameworks haven't even caught up.)

I don't know what version of Ruby it ships (my informant didn't have it
installed) but it's probably 1.8.something.

Nicholas Clark

* Nearly every Linux vendor ships with ithreads enabled, which is a
performance hit. Recompiling without ithreads will get you (probably) a
30% speedup on older versions. If you need ithreads, compiling a newer
version will *still* get you a speedup, because I patched things to reduce
the overhead. You'll also get a faster runloop as of 5.14.0 (my fault, IIRC)
and O(1) ISA lookups instead of O(n) as of 5.10.1 (my fault, IIRC).
Plus a lot of the core SV structures as smaller, which should reduce cache
pressure (my fault).
As a side effect of this, I know I also inadvertently introduced bugs. Most
of which I believe are fixed. It's not humanly possible to change this
codebase without also making mistakes.

[H.Merijn Brand]

That is what OpenSUSE does: 12.2 is the second release of 2012

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

[Michael Schroeder]

On Thu, Feb 07, 2013 at 11:47:01AM +0100, H.Merijn Brand wrote:
> On Wed, 6 Feb 2013 23:02:12 +0100, �var Arnfj�r� Bjarmason

> <ava...@gmail.com> wrote:
>
> > On Wed, Feb 6, 2013 at 7:45 PM, Ricardo Signes
> > <perl...@rjbs.manxome.org> wrote:
> > > We can't call it "Perl {$x>5}" without contradicting Larry.
> >
> > How about "perl 2013.1, the latest implementation of Perl 5 the
> > language".
>
> That is what OpenSUSE does: 12.2 is the second release of 2012

Ah, that's actually coincidence. The next version will be 12.3,
not 13.1.

Cheers,
Michael.

--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}

[Nicholas Clark]

On Thu, Feb 07, 2013 at 11:47:01AM +0100, H.Merijn Brand wrote:

> On Wed, 6 Feb 2013 23:02:12 +0100, Ęvar Arnfjörš Bjarmason

> <ava...@gmail.com> wrote:
>
> > On Wed, Feb 6, 2013 at 7:45 PM, Ricardo Signes
> > <perl...@rjbs.manxome.org> wrote:
> > > We can't call it "Perl {$x>5}" without contradicting Larry.
> >
> > How about "perl 2013.1, the latest implementation of Perl 5 the
> > language".
>
> That is what OpenSUSE does: 12.2 is the second release of 2012

But, of course, that's OpenSUSE's version numbering, not the kernel's.
Which is probably the point - if you ask anyone non-technical what version
of Linux they are running the most common answer you'll probably get is "5"
or "6". Not 2.anything or 3.anything. But the version number of their
distribution.

Which makes me wonder...

The version number isn't the only perceived marketing frustration.
People also express a lot of frustration that the modules they consider
that should be in a distribution aren't in the distribution.

Wouldn't one solution to this whole name/number/stuff conundrum be to take
(say) Chocolate Perl, or some other "batteries included" aggregate
distribution and promote *that*? Its version number doesn't have to be tied
either to 5 or to 18.

Perl doesn't ship with a decent object system? Nonsense, Chocolate Perl does.
etc

Nicholas Clark

[Steve Hay]

Nicholas Clark wrote on 2013-02-07:
> The version number isn't the only perceived marketing frustration.
> People also express a lot of frustration that the modules they
> consider that should be in a distribution aren't in the distribution.
>
> Wouldn't one solution to this whole name/number/stuff conundrum be to
> take (say) Chocolate Perl, or some other "batteries included"
aggregate
> distribution and promote *that*? Its version number doesn't have to be
> tied either to 5 or to 18.
>
> Perl doesn't ship with a decent object system? Nonsense, Chocolate
> Perl does.
> etc
>

Sounds like ActivePerl and Strawberry Perl...

[Dave Mitchell]

On Wed, Feb 06, 2013 at 04:22:17PM +0100, Ovid wrote:
> In that I asked about the pros and cons of renaming Perl 5 to Perl 7. Toby
> Inkster suggested Perl 2013 (and so on).

[ cut big pointless thread ]

Please everyone, can we just stop now?

This is going to be the biggest, most pointless bike-shedding thread in
ages. At least most bike-shedding threads have an underlying reasonable
technical issue to solve (e.g. what to do about smartmatch), even if the
discussion itself meanders.

The issue here is purely about marketing.

If there is a perception that perl5 is old-fashioned and stagnating,
perhaps that's because that indeed is the truth? Pissing about with
versioning schemes isn't going to change that. The only thing it will do
is make us a laughing stock.

And from a technical viewpoint, perl's versioning system is already
asymptotically complex, with $], version objects, "use :5.X", "use feature
:5.X", etc. If we change the perl versioning, we have two options: either
change $] etc to the new scheme (which will just make everything
unfixably complex), or we keep it as is, and have the 'technical version'
(e.g. $]') diverge from the marketing version ("perlhype7, release 20,
platinum edition"). Which will just confuse people.

I remember back in the Nineties when Sun moved from SunOS 4.x to SunOS 5.x,
then Marketing decided to rename it Solaris 2.X (and SunOS 4.x was
retrospectively renamed Solaris 1.x). But uname still identified the
system as SunOS 5.x. It just pissed the heck out of any system admins at
the time.

So why don't we just leave everything as is, and get on with fixing bugs
etc, ready for the new release coming soon? (PS have we have lots
of black smoke at the moment.)

--
"But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged." -- Lady Croom, "Arcadia"

[Nicholas Clark]

On Thu, Feb 07, 2013 at 01:05:02PM +0000, Dave Mitchell wrote:

> And from a technical viewpoint, perl's versioning system is already
> asymptotically complex, with $], version objects, "use :5.X", "use feature
> :5.X", etc. If we change the perl versioning, we have two options: either
> change $] etc to the new scheme (which will just make everything
> unfixably complex), or we keep it as is, and have the 'technical version'
> (e.g. $]') diverge from the marketing version ("perlhype7, release 20,
> platinum edition"). Which will just confuse people.
>
> I remember back in the Nineties when Sun moved from SunOS 4.x to SunOS 5.x,
> then Marketing decided to rename it Solaris 2.X (and SunOS 4.x was
> retrospectively renamed Solaris 1.x). But uname still identified the
> system as SunOS 5.x. It just pissed the heck out of any system admins at
> the time.

The internal version numbers remain on the old sequence:

$ uname -a
SunOS nereid 5.11 11.1 i86pc i386 i86pc Solaris

Same for Java:

$ java -version
java version "1.7.0_09-icedtea"
OpenJDK Runtime Environment (rhel-2.3.4.el5_9.1-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

(that's obviously on a different machine. Just to avoid leaking too much info)


My suggestion was to actually take a distribution (such as Chocolate Perl)
and market *that*. That decouples the version number of the core interpreter
from the version number of the product. And starts to solve the perceived
issues of the wrong batteries being missing.

Nicholas Clark

[David Cantrell]

On Wed, Feb 06, 2013 at 08:18:33PM +0000, Nicholas Clark wrote:
> On Wed, Feb 06, 2013 at 12:10:39PM -0800, Jan Dubois wrote:
> > Note that Mozilla *has* reacted to this issue by making "Extended
> > Support Releases":

> Where "Extended Support" seems to last for about 12 or 13 *months*.
>
> That's better than nothing, but revalidation every year is still going to be
> a pain. However, you get what you pay for.

cpXXXan + CPAN-testers can easily get you three or four years. Beyond
that and you start running into problems such as incompatible compilers
and libraries on newer versions of OSes. Not that anyone who cares that
much about stability will be upgrading their OS willy-nilly.

--
David Cantrell | Pope | First Church of the Symmetrical Internet

Immigration: making Britain great since AD43

[David Golden]

On Thu, Feb 7, 2013 at 5:27 AM, Tim Bunce <Tim....@pobox.com> wrote:
> Let's simply talk in terms of "version 18", "version 19" etc.
> On the mailing list, in release notes, on conference slides.

+1

For example:

diff --git a/Porting/release_announcement_template.txt
b/Porting/release_announcement_template.txt
index 366a498..57e8f07 100644
--- a/Porting/release_announcement_template.txt
+++ b/Porting/release_announcement_template.txt
@@ -2,25 +2,26 @@

-- [ATTRIBUTION]

-We are [SYNONYM FOR 'pleased'] to announce Perl [VERSION], the [N-TH]
-development release of Perl 5.17.
+We are [SYNONYM FOR 'pleased'] to announce version [VERSION.SUBVERSION],
+the [N-TH] development release of version 17 of Perl 5.

-You will soon be able to download Perl [VERSION] from your favorite CPAN
-mirror or find it at:
+You will soon be able to download Perl [VERSION.SUBVERSION] from your
+favorite CPAN mirror or find it at:

-https://metacpan.org/release/[AUTHOR]/perl-[VERSION]/
+https://metacpan.org/release/[AUTHOR]/perl-5.[VERSION.SUBVERSION]/

SHA1 digests for this release are:

- [TAR.GZ SHA1] perl-[VERSION].tar.gz
- [TAR.BZ2 SHA1] perl-[VERSION].tar.bz2
+ [TAR.GZ SHA1] perl-5.[VERSION.SUBVERSION].tar.gz
+ [TAR.BZ2 SHA1] perl-5.[VERSION.SUBVERSION].tar.bz2

You can find a full list of changes in the file "perldelta.pod" located in
the "pod" directory inside the release and on the web.

[ACKNOWLEDGEMENTS SECTION FROM PERLDELTA]

-We expect to release Perl [NEXT BLEAD VERSION] on [FUTURE DATE]. The next
-major stable release of Perl 5, version 5.18.0, should appear in May 2013.
+We expect to release version [NEXT BLEAD VERSION.SUBVERSION] on [FUTURE
+DATE]. The next major stable release of Perl 5, version 18.0, should
+appear in May 2013.

[YOUR SALUATION HERE]



--
David Golden <x...@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

[Mark Overmeer]

* David Golden (x...@xdg.me) [130207 14:06]:

> On Thu, Feb 7, 2013 at 5:27 AM, Tim Bunce <Tim....@pobox.com> wrote:
> > Let's simply talk in terms of "version 18", "version 19" etc.
> > On the mailing list, in release notes, on conference slides.

+1

That certainly gives more "body" to our continuous development.

> +We are [SYNONYM FOR 'pleased'] to announce version [VERSION.SUBVERSION],
> +the [N-TH] development release of version 17 of Perl 5.

Maybe disambigue the use of "version".

Release 8 of generation 17 of Perl version 5

We proudly present Perl 5 generation 18, another major step in
our continuous effort to improve the language.

In the style of "XYZ Next Generation"
--
Regards,

MarkOv

------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
Ma...@Overmeer.net solu...@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net

[Joel Berger]

From: Ricardo Signes <perl...@rjbs.manxome.org>
To: Ovid <curti...@gmail.com>
Cc: perl5-...@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

[Alexander Hartmaier]

The Java guys did that years ago and it seems to have worked for them. +1 from me to apply it.

[David Golden]

On Thu, Feb 7, 2013 at 9:35 AM, Ricardo Signes
<perl...@rjbs.manxome.org> wrote:
> Looks fine to me, apply it.

Applied as commit b0ceb856efb2614e7cdfb3c8c4c08362b2065854

[John Imrie]

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

[Alexander Hartmaier]

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

[Johan Vromans]

Ricardo Signes <perl...@rjbs.manxome.org> writes:

> Bonus points for checking things like grep.cpan.me for an idea of *how
> much* code would break.

Is the *how much* corrected for the *actual use* of the modules?
Breaking modules that are never or hardly ever used (99% of CPAN, rough
estimate) is less serious than breaking the top 100/500/whatever of
popular CPAN modules...

-- Johan

[Alexander Hartmaier]

On Thu, Feb 7, 2013 at 11:05 PM, Ricardo Signes <perl...@rjbs.manxome.org> wrote:

* Alexander Hartmaier <alex.ha...@gmail.com> [2013-02-07T17:00:31]

> 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).

We have made backward-incompatible changes, on occasion.

Why don't you propose *specific things* and *one at a time*.  Bonus points for

checking things like grep.cpan.me for an idea of *how much* code would break.

I also strongly suggest that you explain how the breakage adds *specific*
value.  "Let's drop a rarely used feature because it is rarely used." is not
that.

--
rjbs

 

I wouldn't call it dropping 'features' but getting rid of old and foremost not recommended ways of doing things because of side-effects that a new or occasional Perl coder doesn't know.
I also don't think that such changes break a lot of CPAN modules, at least not the maintained and often used ones because they are written by senior Perl coders and don't use the mentioned styles.

[Joseph Brenner]

Dave Mitchell <da...@iabyn.com> wrote:

"The issue here is purely about marketing."

Correct. The suggestion is that there's a simple, nearly-free change
that could be made that would improve perl's standing in the world.
But if it doesn't involve lots of code, we can't manage the decision.

Personally, I like the "perl YYYY" idea: it makes it clear that new
versions of perl are coming out without (too much) nose thumbing at
the Perl 6 project for taking some time.

On the other hand, if we need to get Larry to sign off on the idea, we
might go with perl6 instead of perl7 and offer him the lucky 7 to work
with.

[Jeffrey Ryan Thalhammer]

I started cooking a big editorial essay in my head, but I'm just going to try and boil it down…

So long as a fixed number ("5" in this case) is *prominently* attached to Perl, it will be seen as stuck. Specifically, it is stuck behind that thing called "Perl6".

You may understand the distinction between "Perl" and "Perl5" and "perl-5.16.2", but the rest of the world (including many developers) does not.

Others (notably Apple, Java, Mozilla) understand how to manage perceptions through names and numbers. We should learn from them.

Continuing the affiliation between Perl5 and Perl6 is harmful to both camps. Negative perceptions about either needlessly end up affecting both.

The Perl5 community must pursue its own best interests and cannot be held hostage by the name and number of another language.

Establishing a way forward through both minor and major (i.e. non-backcompat) releases to Perl5 will help to energize and accelerate development.

The Perl6 community will not take offense at anything the Perl5 community does. We all understand that we have common roots, but we are now on separate paths.

I will not argue whether Perl is thriving or dying, but I will assert that the language and community does not receive as much "buzz" as it deserves.

Rebranding, renaming, and/or renumbering are useful tools for generating "buzz." But these alone are not sufficient -- a compelling message is also required.

Initial reactions to these kinds of changes are always mixed. But those feelings will fade and the benefits will come over time.

Yes, this is mostly about marketing and image, but that doesn't mean it isn't worthwhile. Perceptions do matter, regardless of whether they are rational.

Not everyone in the community cares about marketing, but we must not impede or discourage those who do. We are all on the same team.

If we want things to *be* different, than we must *do* things differently. Let us not be afraid to try.

-Jeff

[bulk88]

Jeffrey Ryan Thalhammer wrote:
> I started cooking a big editorial essay in my head, but I'm just
> going to try and boil it down…
>
> So long as a fixed number ("5" in this case) is *prominently*
> attached to Perl, it will be seen as stuck. Specifically, it is
> stuck behind that thing called "Perl6".

Agree.

>
> You may understand the distinction between "Perl" and "Perl5" and

> "perl-5.16.2", but therest of the world (including many developers)
> does not.

Agree. Imagine if Javascript was called Java 2.0.

>
> Others (notably Apple, Java, Mozilla) understand how to manage
> perceptions through names and numbers. We should learn from them.
>
> Continuing the affiliation between Perl5 and Perl6 is harmful to both
> camps. Negative perceptions about either needlessly end up affecting
> both.

Agree. Often the people who choose to use Perl (and its programmers),
are not Perl programmers, and are not programmers themselves but just
management. There is no way to convince someone that Perl 6 is not the
successor to Perl 5, and Perl 5 is deprecated. I must be nuts to invest
in the dead Perl 5 where any day support is going to be dropped in favor
of Perl 6 but oh, Perl 6 isn't finished, it might be next year and all
my code is dead then.

>
> The Perl5 community must pursue its own best interests and cannot be
> held hostage by the name and number of another language.

Agree.

>
> The Perl6 community will not take offense at anything the Perl5
> community does. We all understand that we have common roots, but we
> are now on separate paths.

Agree.

>
> I will not argue whether Perl is thriving or dying, but I will assert
> that the language and community does not receive as much "buzz" as it
> deserves.
>
> Rebranding, renaming, and/or renumbering are useful tools for
> generating "buzz." But these alone are not sufficient -- a
> compelling message is also required.
>

The message is, Perl is maintained and alive, but those 2 words aren't
buzzwords.

> Initial reactions to these kinds of changes are always mixed. But
> those feelings will fade and the benefits will come over time.
>
> Yes, this is mostly about marketing and image, but that doesn't mean
> it isn't worthwhile. Perceptions do matter, regardless of whether
> they are rational.

Agree.

>
> Not everyone in the community cares about marketing, but we must not
> impede or discourage those who do. We are all on the same team.

Agree.

[Konovalov, Vadim (Vadim)** CTR **]

> From: Dave Mitchell [mailto:da...@iabyn.com]

> Please everyone, can we just stop now?

.....

> The issue here is purely about marketing.

This issue 1)exists and 2) appears to be important, as was
explained by the OP.

> And from a technical viewpoint, perl's versioning system is already
> asymptotically complex, with $], version objects, "use :5.X",
> "use feature :5.X", etc.

this is yet another problem, but it isn't as big.

> I remember back in the Nineties when Sun moved from SunOS 4.x
> to SunOS 5.x,
> then Marketing decided to rename it Solaris 2.X (and SunOS 4.x was
> retrospectively renamed Solaris 1.x). But uname still identified the
> system as SunOS 5.x. It just pissed the heck out of any
> system admins at the time.

Rare people remember anything wrong with this (I don't).
I knew nothing about SunOS-to-Solaris, yet I knew about Sun and Solaris
but I was perfectly happy with both of them, for whatever reasons.

Sometimes companies do re-branding, due to some reasons.

IMO the moment come for perl5 to replace "5" to something.
(empty string, 7, star, plus, "astoria", Andromeda, M31, etc - all works for me, except 5 :)

> So why don't we just leave everything as is, and get on with
> fixing bugs
> etc, ready for the new release coming soon? (PS have we have lots
> of black smoke at the moment.)

Just ignoring the problem and switching to the pure technical issues
isn't a balanced solution.

Vadim.

[Johan Vromans]

"Konovalov, Vadim (Vadim)** CTR **" <vadim.k...@alcatel-lucent.com>
writes:

> Sometimes companies do re-branding, due to some reasons.

I recently read an article (in dutch, but I can't find it anymore) that
correlated brand renaming to bankruptcy. It seems that most cases of
brand renaming were a last effort to draw attention to a product, and
failed horribly.

The article was written in response to the RIM -> BlackBerry renaming.

See also my response to Joseph Brenner elsewhere.

-- Johan

[Johan Vromans]

Joseph Brenner <doo...@gmail.com> writes:

> Correct. The suggestion is that there's a simple, nearly-free change
> that could be made that would improve perl's standing in the world.

Small nitpick: Other organisations that tried this did *two* things:
they renamed/renumberd the product *and* generated a lot of publicity
accompanying the change.

We can change the version number, but we suck at marketing...

-- Johan

[Konovalov, Vadim (Vadim)** CTR **]

> From: Johan Vromans [mailto:jvro...@squirrel.nl]

> "Konovalov, Vadim writes:
>
> > Sometimes companies do re-branding, due to some reasons.
>
> I recently read an article (in dutch, but I can't find it
> anymore) that
> correlated brand renaming to bankruptcy. It seems that most cases of
> brand renaming were a last effort to draw attention to a product, and
> failed horribly.

can not argue about that article... maybe it has valid points.

But there are lot of examples of successfull re-branding...

GoldStar -> LG isn't an epic fail, yet there are many examples of successful
re-branding in my country.

the point is - usually rebranding done due to some reasons,
and - due to current circumstances - perl has real reasons to consider that.

Not a full name change, but s{5}{smth} is something to consider

[Jeffrey Ryan Thalhammer]

On Feb 8, 2013, at 12:37 AM, Johan Vromans wrote:

I recently read an article (in dutch, but I can't find it anymore) that
correlated brand renaming to bankruptcy. It seems that most cases of
brand renaming were a last effort to draw attention to a product, and
failed horribly.

Nonsense.  That thinking is a perfect example of survivorship bias (only reversed).

Plenty of organizations/products have successfully "reinvented" their image through strategic messaging and marketing.  And plenty of organizations/products have also failed at it.

But all those organizations/products did it because they felt they were headed in the wrong direction.  Some would eventually fail even if they did not try to turn the ship around.

So we tend to forget about the good reinventions because they are still with us.  We only remember the bad ones because we need to explain their absence.

Also, correlation does not equate to causation.

-Jeff

[Alexander Hartmaier]

Maybe we should approach this differently: how would the Perl version numbers have developed if Perl 6 hasn't been there?
Would 5.10 have been 6.0? Or 5.12 because it would have been able to enabled strict by default instead of just under use 5.012;?
This only teachs us that experiments like Perl 6 should use a codename instead of choosing the next version number while under development.
Would it help to free the version number 6 by asking the Perl 6 folks to rename it for the time being to something else?
Obviously there are people (Stevan) that want Perl 5.5 in the sense that they don't want to invest their time into finishing Perl 6 nor working on the Perl 5 core as it is now.
To me that looks like a (not so) quick fix for a deeper problem. I'd appreciate implementing another compiler for the perl 6 syntax but not inventing a hybrid (Perl 5+?).

[Dave Mitchell]

On Thu, Feb 07, 2013 at 11:00:31PM +0100, Alexander Hartmaier wrote:
> My feeling is that p5p cares too much about backward compatibility!

No we don't. I for one would be extremely annoyed if half my admin scripts
stopped working (or silently started misbehaving) just because I updated
my OS, which happened to include a newer bundled perl version.

> Old
> code will run on old Perl versions, they won't stop doing that when a new
> Perl version is released!

But very soon, old perls stop building on new platforms.

> 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!

Brillant! "We've broken all your code, but its your fault because you
didn't read the release notes carefully enough!"

--
Art is anything that has a label (especially if the label is "untitled 1")

[H.Merijn Brand]

On Fri, 8 Feb 2013 15:10:29 +0000, Dave Mitchell <da...@iabyn.com>
wrote:

> On Thu, Feb 07, 2013 at 11:00:31PM +0100, Alexander Hartmaier wrote:
> > My feeling is that p5p cares too much about backward compatibility!
>
> No we don't. I for one would be extremely annoyed if half my admin scripts
> stopped working (or silently started misbehaving) just because I updated
> my OS, which happened to include a newer bundled perl version.
>
> > Old code will run on old Perl versions, they won't stop doing that when a new
> > a new Perl version is released!
>
> But very soon, old perls stop building on new platforms.

Why? I really try hard to make sure modern perl builds on nearly-dead
OS's I have access to.

> > 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!
>
> Brillant! "We've broken all your code, but its your fault because you
> didn't read the release notes carefully enough!"

DaveM++ !! :)

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

[Dave Mitchell]

On Thu, Feb 07, 2013 at 03:19:18PM -0800, Joseph Brenner wrote:
> Dave Mitchell <da...@iabyn.com> wrote:
>
> "The issue here is purely about marketing."
>
> Correct. The suggestion is that there's a simple, nearly-free change
> that could be made that would improve perl's standing in the world.
> But if it doesn't involve lots of code, we can't manage the decision.

No, my objection is that it's a change for essentially zero gain.
Perl's prospects aren't going to magically transformed by introducing a
new versioning scheme.

--
Never work with children, animals, or actors.

[Nicholas Clark]

This is also my view. *Just* changing the version scheme isn't going to
convince anyone of anything for very long. It will actually look worse
when it becomes apparent that it's nothing substantive.


A visible version lurch also needs to offer something new or different.

Hence why I suggested taking something like Chocolate Perl (or, I guess
Task::Kensho), making a "batteries included" distribution, distinct from
the core, and promoting *that*.

Note, that distinction is needed, because

1) Such a "batteries included" distribution is likely to only usefully build
on a few common platforms. (I'd guess Win32, OS X and common Linux
architectures)
2) Downstream Linux and *BSD distributions wouldn't use it as their "perl"
package. They are already concerned about the size of the perl install,
and how they fit it onto installation media.

It's a fast way to get to something reasonably substantive. It also side-steps
the issue that many people/firms are sticking on the vendor supplied
/usr/bin/perl, because it explicitly is something they have to install.

Nicholas Clark

[bulk88]

Dave Mitchell wrote:
> On Thu, Feb 07, 2013 at 11:00:31PM +0100, Alexander Hartmaier wrote:
>> My feeling is that p5p cares too much about backward compatibility!
>
> No we don't. I for one would be extremely annoyed if half my admin scripts
> stopped working (or silently started misbehaving) just because I updated
> my OS, which happened to include a newer bundled perl version.
>

If someone cant afford to budget time to test anything, they shouldn't
be updating their OS.

>> Old
>> code will run on old Perl versions, they won't stop doing that when a new
>> Perl version is released!
>
> But very soon, old perls stop building on new platforms.

But someone can say "you broke all my Perl code because you dropped my
OS". I know the reply to that will be "you didn't do anything about it
when we announced it".

>
>> 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!
>
>
> Brillant! "We've broken all your code, but its your fault because you
> didn't read the release notes carefully enough!"
>

That is life. A security fix broke your code. What do you do? Revert it
since they had no right to break your code? Also the term "RTFM" comes
to mind.

[Jesse Luehrs]

On Fri, Feb 08, 2013 at 01:02:38PM -0500, bulk88 wrote:
> Dave Mitchell wrote:
> >On Thu, Feb 07, 2013 at 11:00:31PM +0100, Alexander Hartmaier wrote:
> >>My feeling is that p5p cares too much about backward compatibility!
> >
> >No we don't. I for one would be extremely annoyed if half my admin scripts
> >stopped working (or silently started misbehaving) just because I updated
> >my OS, which happened to include a newer bundled perl version.
> >
>
> If someone cant afford to budget time to test anything, they
> shouldn't be updating their OS.

You can say this all you want, but it's not going to stop people from
doing it.

> >>Old
> >>code will run on old Perl versions, they won't stop doing that when a new
> >>Perl version is released!
> >
> >But very soon, old perls stop building on new platforms.
>
> But someone can say "you broke all my Perl code because you dropped
> my OS". I know the reply to that will be "you didn't do anything
> about it when we announced it".

There's a difference between code that we dislike because it's hard to
maintain and code that is not actually possible to maintain because we
don't have access to the appropriate environment. We're only dropping
support for platforms that will likely end up broken anyway (if they
aren't already) because nobody has access to those systems anymore. This
is different from dropping support for features that we are capable of
modifying and testing.

> >>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!
> >
> >
> >Brillant! "We've broken all your code, but its your fault because you
> >didn't read the release notes carefully enough!"
> >
>
> That is life. A security fix broke your code. What do you do? Revert
> it since they had no right to break your code? Also the term "RTFM"
> comes to mind.

RTFM is an absolutely awful strategy for basically any kind of dealing
with people at all. Please don't suggest that as an actual real path we
should take.

-doy

[Christian Walde]

On Fri, 08 Feb 2013 09:40:41 +0100, Johan Vromans <jvro...@squirrel.nl>
wrote:

> Small nitpick: Other organisations that tried this did *two* things:
> they renamed/renumberd the product *and* generated a lot of publicity
> accompanying the change.
>
> We can change the version number, but we suck at marketing...

That's what mdk and the TPF are there for.

--
With regards,
Christian Walde

[David Cantrell]

How about starting by getting a list of modules from grep.cpan.me, and
then using CPANdeps to see what uses them?

--
David Cantrell | even more awesome than a panda-fur coat

Guns aren't the problem. People who deserve to die are the problem.

[Johan Vromans]

David Cantrell <da...@cantrell.org.uk> writes:

> How about starting by getting a list of modules from grep.cpan.me, and
> then using CPANdeps to see what uses them?

What we need to know is which modules are used by application code that
is running at user sites.

Alternatively, some kind of popularity / quality voting on the CPAN site.

-- Johan

[Greg Lindahl]

I would love to have something that I could wire into my build system
that would report, every few weeks, all the CPAN modules that I use,
along with a count of how many servers I deploy code on. It would need
to be cleverly designed to keep the data fresh, and of course not
every organization would want to report even approximate server
counts, but it could be a huge help in knowing the popularity of
various modules.

-- greg

[demerphq]

IMO you would get more intelligent discussion on this subject if you
started a new thread.

This one I think is, er, nailed to the perch...

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

[Johan Vromans]

Greg Lindahl <gr...@blekko.com> writes:

> I would love to have something that I could wire into my build system
> that would report, every few weeks, all the CPAN modules that I use,

The best tool for this is perl itself. We would need a very light-weight
way to store some usage data upon termination. A shared memory file,
maybe?

-- Johan

[Dominic Hargreaves]

Debian uses[1] atimes to record this; obviously no good where that's not
supported/enabled by the filesystem, but it's another option to consider.

It'd be feasible to extract the data for CPAN modules (lib*-perl, roughly)
and publish a CPAN-specific report somewhere, I'd have thought.

[1] <http://popcon.debian.org/>

--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

[David Golden]

If you have Path::Iterator::Rule and a filesystem that supports atime:

$ perl -MPath::Iterator::Rule -wE 'say for
Path::Iterator::Rule->new->skip_dirs(".")->perl_module->accessed("<7")->all(@INC)'

(For modules used in the last week.)

I leave it to the reader to convert that back to a list of modules.

--
David Golden <x...@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

[Johan Vromans]

Dominic Hargreaves <d...@earth.li> writes:

> Debian uses[1] atimes to record this; obviously no good where that's
> not supported/enabled by the filesystem, but it's another option to
> consider.

atime will only show *if* a module was used, and you'd still have to
scan all disks for users that installed their own CPAN modules.

What I meant what that the perl interpreter keeps a tally of the modules
it loads, and registers that somewhere. Not many users will install
their own perl interpreters.

-- Johan

[demerphq]

On 12 February 2013 12:16, David Golden <x...@xdg.me> wrote:
> On Tue, Feb 12, 2013 at 3:51 AM, Johan Vromans <jvro...@squirrel.nl> wrote:
>> Greg Lindahl <gr...@blekko.com> writes:
>>
>>> I would love to have something that I could wire into my build system
>>> that would report, every few weeks, all the CPAN modules that I use,
>>
>> The best tool for this is perl itself. We would need a very light-weight
>> way to store some usage data upon termination. A shared memory file,
>> maybe?
>
> If you have Path::Iterator::Rule and a filesystem that supports atime:
>
> $ perl -MPath::Iterator::Rule -wE 'say for
> Path::Iterator::Rule->new->skip_dirs(".")->perl_module->accessed("<7")->all(@INC)'
>
> (For modules used in the last week.)
>
> I leave it to the reader to convert that back to a list of modules.

What, the solution doesn't fit into this margin? ;-)

[Dominic Hargreaves]

On Tue, Feb 12, 2013 at 12:57:26PM +0100, Johan Vromans wrote:
> Dominic Hargreaves <d...@earth.li> writes:
>
> > Debian uses[1] atimes to record this; obviously no good where that's
> > not supported/enabled by the filesystem, but it's another option to
> > consider.
>
> atime will only show *if* a module was used, and you'd still have to
> scan all disks for users that installed their own CPAN modules.
>
> What I meant what that the perl interpreter keeps a tally of the modules
> it loads, and registers that somewhere.

I'm not sure that sort of complication embedded into the core
interpreter will be welcome; the advantage of the atime method is that
it doesn't impose any new penalty on the system.

A separate reporting process would need to run periodically, similar
to the popcon program which runs on Debian systems. In terms of assessing
impact, I don't think counting the number of times a module is loaded
is that useful -- that would weight some modules which tend to be used
by short-running processes higher than those used by longer-running
processes. Popcon in Debian has the concept of a vote where the file has
been used in the past week, which is probably fine for the perl/CPAN
world too; just needs the reporting agent to run once a week.

> Not many users will install
> their own perl interpreters.

I agree, so isn't this a reason to keep the data collection out of it?

[Jan Dubois]

Forgot to CC p5p


---------- Forwarded message ----------
From: Jan Dubois <ja...@activestate.com>
Date: Tue, Feb 12, 2013 at 11:16 AM
Subject: Re: Keeping track of used modules (Was: Perl 7 or Perl 2013?)
To: demerphq <deme...@gmail.com>

Put this into your sitecustomize.pl file:

END { require DB_File; tie my %h, "DB_File", "$ENV{HOME}/zzz";
$h{$_}++ for values %INC }

Demo:

$ perl -Mstrict -E 'END { require DB_File; tie my %h, "DB_File",
"$ENV{HOME}/zzz"; $h{$_}++ for values %INC} say 42'
42
$ perl -MDB_File -E 'tie %h, "DB_File", "$ENV{HOME}/zzz"; printf "%s:
%d\n", $_, $h{$_} for sort keys %h'
/usr/local/ActivePerl-5.16/lib/AutoLoader.pm: 1
/usr/local/ActivePerl-5.16/lib/Carp.pm: 1
/usr/local/ActivePerl-5.16/lib/DB_File.pm: 1
/usr/local/ActivePerl-5.16/lib/Exporter.pm: 1
/usr/local/ActivePerl-5.16/lib/Fcntl.pm: 1
/usr/local/ActivePerl-5.16/lib/File/Spec.pm: 1
/usr/local/ActivePerl-5.16/lib/File/Spec/Unix.pm: 1
/usr/local/ActivePerl-5.16/lib/Tie/Hash.pm: 1
/usr/local/ActivePerl-5.16/lib/XSLoader.pm: 1
/usr/local/ActivePerl-5.16/lib/auto/DB_File/autosplit.ix: 1
/usr/local/ActivePerl-5.16/lib/feature.pm: 1
/usr/local/ActivePerl-5.16/lib/strict.pm: 1
/usr/local/ActivePerl-5.16/lib/vars.pm: 1
/usr/local/ActivePerl-5.16/lib/warnings.pm: 1
/usr/local/ActivePerl-5.16/lib/warnings/register.pm: 1
/usr/local/ActivePerl-5.16/site/lib/sitecustomize.pl: 1

Cheers,
-Jan

[David Golden]

On Tue, Feb 12, 2013 at 2:35 PM, Jan Dubois <ja...@activestate.com> wrote:
> Put this into your sitecustomize.pl file:
>
> END { require DB_File; tie my %h, "DB_File", "$ENV{HOME}/zzz";
> $h{$_}++ for values %INC }

Nice.

A distro package like AS or Strawberry could easily create a popcon
like tracker with that (albeit with some non-trivial web request
overhead).

David

[Greg Lindahl]

On Tue, Feb 12, 2013 at 11:35:45AM -0800, Jan Dubois wrote:

> Put this into your sitecustomize.pl file:
>
> END { require DB_File; tie my %h, "DB_File", "$ENV{HOME}/zzz";
> $h{$_}++ for values %INC }

That's quite awesome. Like most big perl shops, we have a lot of
perversity about our environment that makes the atime thing hard, but
this concept works perfectly! Just to give you an idea, we have

* noatime on all disks
* a separate install tree of Perl modules for each of a dozen
long-lived processes
* said daemons are crash-only (kill -9 == no END)
* some normal short-lived scripts, too

In addition to using END (for short-lived scripts) I'll just have the
daemons report daily, sweep everything up, et voila! A little cleaning
of the data, and I'd be happy to make it public.

-- greg

[Johan Vromans]

Dominic Hargreaves <d...@earth.li> writes:

> I'm not sure that sort of complication embedded into the core
> interpreter will be welcome; the advantage of the atime method is that
> it doesn't impose any new penalty on the system.

All methods have pros and cons. But currently we have no clue at all, so
any information would be an improvement.

> that would weight some modules which tend to be used by short-running
> processes higher than those used by longer-running processes.

Yes, it is not possible to simply establish the importance/impact of
each module for a given user.

> Popcon in Debian has the concept of a vote where the file has
> been used in the past week, which is probably fine for the perl/CPAN
> world too; just needs the reporting agent to run once a week.

You're still overlooking the modules that are not installed in
/usr/lib/perl5.

>> Not many users will install their own perl interpreters.
>
> I agree, so isn't this a reason to keep the data collection out of it?

As said, all methods have pros and cons.

I do not pretend to have all answers.

-- Johan

[Johan Vromans]

Greg Lindahl <gr...@blekko.com> writes:

> In addition to using END (for short-lived scripts) I'll just have the
> daemons report daily, sweep everything up, et voila!

This will introduce some weighting, which is good.

-- Johan

[Johan Vromans]

Jan Dubois <ja...@activestate.com> writes:

> END { require DB_File; tie my %h, "DB_File", "$ENV{HOME}/zzz";
> $h{$_}++ for values %INC }

A raw dump of %INC would be fine, and requires less overhead, e.g.

END {
open my $fh, '>>', "$ENV{HOME}/zzz";
print { $fh } localtime, " $$\n",
map { "$_\n" } for values %INC;
}

-- Johan

[David Golden]

On Wed, Feb 13, 2013 at 1:53 AM, Greg Lindahl <gr...@blekko.com> wrote:
> In addition to using END (for short-lived scripts) I'll just have the
> daemons report daily, sweep everything up, et voila! A little cleaning
> of the data, and I'd be happy to make it public.

If you don't want to rely on END, then the other way I'd go about it
would be to use an @INC hook to record things at require time. You
have a little trickiness if things modify @INC ('use lib'). Something
that overrides CORE::GLOBAL::require would work, too, but then you
have to be sure to get the semantics of require exactly right. (I
also wonder if %INC is tie-able?)

There are plenty of such things on CPAN -- you'd have to figure out if
any serve or adapt your own.

Devel::TraceDeps
Devel::Loaded
Devel::TraceUse
etc.

David

[bulk88]

FWIW AS's PPM site http://code.activestate.com/ppm/search:/ has download
counts. They mean something. I dont know how "real world" they are
though (did someone push a AS PPM module to 200 desktops with Active
Directory? so thats 200 downloads, but only 1 user).

[David Golden]

On Wed, Feb 13, 2013 at 12:59 PM, bulk88 <bul...@hotmail.com> wrote:
>>> I would love to have something that I could wire into my build system
>>> that would report, every few weeks, all the CPAN modules that I use,
>

> FWIW AS's PPM site http://code.activestate.com/ppm/search:/ has download
> counts. They mean something. I dont know how "real world" they are though
> (did someone push a AS PPM module to 200 desktops with Active Directory? so
> thats 200 downloads, but only 1 user).

That's a different questions. The OP said: "report ... CPAN modules
that *I* use" [emphasis added]

[Peter Martini]

On Wed, Feb 13, 2013 at 4:52 PM, David Golden <x...@xdg.me> wrote:
> On Wed, Feb 13, 2013 at 12:59 PM, bulk88 <bul...@hotmail.com> wrote:
>>>> I would love to have something that I could wire into my build system
>>>> that would report, every few weeks, all the CPAN modules that I use,
>>
>> FWIW AS's PPM site http://code.activestate.com/ppm/search:/ has download
>> counts. They mean something. I dont know how "real world" they are though
>> (did someone push a AS PPM module to 200 desktops with Active Directory? so
>> thats 200 downloads, but only 1 user).
>
> That's a different questions. The OP said: "report ... CPAN modules
> that *I* use" [emphasis added]
>

I don't know the current status of dtrace (inside perl or how many
OSes support it), but this seems like the kind of question it would be
useful for.

[Johan Vromans]

David Golden <x...@xdg.me> writes:

> That's a different questions. The OP said: "report ... CPAN modules
> that *I* use" [emphasis added]

While that is true, the original question that started this thread was
how to track module use globally to obtain figures to be used as
weighting factors in deciding how severe module breakage due to perl
improvements is.

-- Johan

[David Cantrell]

On Wed, Feb 13, 2013 at 10:51:52AM -0500, David Golden wrote:

> If you don't want to rely on END, then the other way I'd go about it
> would be to use an @INC hook to record things at require time. You
> have a little trickiness if things modify @INC ('use lib').

You could always provide your own lib::import, like Sub::WrapPackages
does.

> (I also wonder if %INC is tie-able?)

I vaguely recall trying to do that in the past, and failing.

--
David Cantrell | semi-evolved ape-thing

All children should be aptitude-tested at an early age and,
if their main or only aptitude is for marketing, drowned.

[Johan Vromans]

David Cantrell <da...@cantrell.org.uk> writes:

> You could always provide your own lib::import, like Sub::WrapPackages
> does.

Would it be possible to do something similar to the Linux Counter?

Have people register at a site, provide a script that they can run
periodically and that finds out what modules are installed (preferrably
with atime information) and reports this back to the server?

Although not perfect this might yield usuable statistics.

-- Johan